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ABSTRACT 


The  purpose  of  this  thesis  is  to  investigate  using  Global  Positioning  System  (GPS) 
technology,  for  the  guidance  of  an  unmanned  air  vehicle  (UAV)  seeking  precise 
navigation.  Being  fully  operationally  deployed  by  now,  GPS  is  the  indispensable  tool  for 
every  application  that  requires  precise  positioning.  By  applying  the  Differential 
Positioning  technique,  GPS  becomes  accurate  to  the  point  that  its  position  and  velocity 
outputs  can  be  used  as  inputs  to  a  flight  control  computer  of  a  UAV. 

The  Archytas  unmanned  airborne  vehicle  at  the  Naval  Postgraduate  School  will 
achieve  autonomous  flight  using  a  Texas  Instruments  TMS320C30  Digital  Signal 
Processor.  The  latter  is  hosted  on  an  IBM  compatible  PC,  and  is  controlled  via  Integrated 
System's  AC  1 00  control  system  design  and  implementation  software  package 

The  GPS  receiver  used  throughout  this  thesis  is  a  Motorola  PVT-6  OEM. 
Another  identical  GPS  receiver  is  used  as  a  reference  station,  enhancing  the  former  with 
Differential  capability.  Finally,  the  achieved  accuracy  of  the  differential  setup  is  examined 
with  respect  to  the  Archytas  flight  controller  requirements. 
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I.  INTRODUCTION 


Since  the  dawn  of  civilization,  navigation  was  one  of  the  big  concerns 
of  human  beings.  The  question  "where  am  I?"  or  "where  am  I  going?",  was 
vital  for  survival  whenever  primitive  man  left  his  settlement  to  fulfill  his 
everyday  needs  or  esoteric  motivations. 

During  his  long  struggle  to  explore  and  conquer  the  globe,  man  has 
many  times  turned  his  eyes  to  the  sky  looking  for  help  with  his  navigation.  The 
stars  could  help  a  navigator  find  his  way  from  one  continent  to  another  but 
could  not  help  him  avoid  deadly  reefs,  or  find  a  harbor  entrance  in  the  night. 
Many  navigation  tools  have  been  used  since  then,  some  more  efficient  than 
others,  but  today  man  once  more  turns  his  eyes  to  the  sky  in  order  to  solve 
once  and  for  all  his  navigation  problems  around  the  globe.  He  is  now  aided  by 
man  made  stars. 

A  true  revolution  in  the  world  of  navigation,  the  Global  Positioning 
System  (GPS)  was  born  in  1973  after  a  small  group  of  Armed  Forces  officers 
and  civilians  completed  a  plan  which  proposed  that  precise  navigation  could  be 
achieved  by  using  radio-ranging  measurements  to  a  constellation  of  artificial 
satellites  called  NAVSTAR's. 

Two  decades  later,  that  early  plan  became  a  reality.  Twenty  four  on 
orbit  satellites  give  GPS  its  full  operational  capability,  providing  uninterrupted 
signal  coverage  around  the  globe  and  changing  many  of  the  traditional  ways 
that  man  obtained  his  positioning.  The  system  is  owned  by  the  United  States 
Air  Force  and  managed  jointly  by  the  Department  of  Defense  and  the 
Department  of  Transportation.  As  soon  as  the  system  became  available  to  the 
public,  it  was  embraced  by  all  those  interested  in  precise  navigation,  becoming 
a  unique  utility  which  is,  day  by  day,  pushing  aside  the  existing  navigation 
systems. 
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The  aviation  community  is  one  of  the  Global  Positioning  System's  most 
dedicated  users.  The  military  is  taking  advantage  of  the  system's  full 
operational  capabilities  which  allow  it  to  pinpoint  aerial  vehicle's  position  with 
an  accuracy  of  about  seven  meters,  while  the  civilian  users  are  offered  a 
navigation  signal  of  degraded  accuracy,  with  an  average  error  of  about  one 
hundred  meters.  The  civilian  accessible  signal  is  transmitted  at  a  different 
frequency  than  the  military  one,  with  its  accuracy  intentionally  degraded  by 
introducing  errors  in  several  critical  navigational  parameters  transmitted  by  it. 
This  is  in  response  to  the  Department  of  Defense's  concerns  for  preventing 
unauthorized  use  of  this  navigation  utility  by  hostile  forces  against  the  United 
States. 

To  compensate  for  this  degradation,  a  corrective  technique  has  been 
introduced  which  is  called  Differential  GPS.  The  idea  is  that  a  stationary 
receiver,  (called  base  station),  with  its  position  known,  can  extract  the  needed 
correction  for  the  erroneous  navigational  parameters  transmitted  by  the  GPS 
signal,  by  comparing  the  position  fix  that  it  calculates  from  the  satellite  signal 
with  its  a  priori  known  position.  These  corrections  are  good  for  receivers 
located  within  several  hundred  miles  from  the  base  station  and  can  be  made 
available  by  radio  broadcast. 

The  accuracy  of  determining  position  using  the  Differential  GPS 
(DGPS)  technique  has  a  typical  value  of  less  than  three  meters.  With  such  a 
level  of  accuracy,  DGPS  is  looking  particularly  elegant  in  applications  where 
precise  positioning  information  is  important,  such  as  the  flight  control  of  an 
unmanned  aerial  vehicle  (UAV).  To  ensure  continuous  and  smooth  control  of 
the  UAV's  flight  path,  the  GPS  provided  position  fix  should  be  blended  with 
the  outputs  of  an  inertial  measurement  unit.  This  is  mainly  because  of  the 
following  reasons: 
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•  The  currently  manufactured  GPS  receiver  units  output  position  information 
usually  once  per  second,  a  rate  that  is  insufficient  to  provide  real  time  position 
of  the  vehicle  when  the  latter  experiences  large  accelerations. 

Due  to  temporary  signal  loss  that  can  happen  for  various  reasons,  the  GPS 
receiver  may  not  be  able  to  provide  navigation  solution  for  a  period  of  time. 
Although  the  time  length  associated  with  such  situations  is  usually  not  more 
than  a  few  seconds,  is  still  enough  to  cause  the  loss  of  the  vehicle's  position 
control. 

♦  The  positioning  solution  offered  by  GPS  is  "wandering  around"  due  to  various 
navigational  errors,  thus  creating  the  necessity  for  the  integration  with  the  more 
stable  inertial  measurement  unit. 

The  research  effort  described  in  this  document  is  to  provide  three  dimensional 
positioning  information  to  the  computer  controlling  the  flight  of  the  Archytas 
UAV  at  the  Naval  Postgraduate  School,  using  Differential  Global  Positioning 
System  technology.  In  the  following  chapters,  we  discuss  the  GPS  receivers 
used,  the  flight  control  computer,  and  the  way  in  which  they  are 
interconnected.  The  appendices  include  the  receiver  specifications,  the  figures, 
as  well  the  C  code  needed  to  interface  between  the  two  machines  i.e.,  the  GPS 
receiver  and  the  flight  control  computer. 
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II.  the  global  positioning  system 


In  order  to  fully  understand  and  evaluate  the  positioning  information 
obtained  by  the  GPS,  its  principles  of  operation  will  be  discussed.  The  system 
consists  of  three  major  segments: 

♦  The  space  segment 

♦  The  control  segment 

♦  The  user  segment 

Although  the  last  segment  is  apparently  the  most  interesting  for  the  present 
application,  the  other  two  segments  are  also  presented.  The  whole  system  is 
presented  in  Fig.2.1. 


A.  THE  SPACE  SEGMENT 

The  fully  operational  space  segment  consists  of  twenty  four  satellites 
that  are  placed  in  six  different  orbital  planes  at  an  altitude  of  10,898  nautical 
miles  above  the  surface  of  the  earth.  The  first  satellite,  model  Block  I,  was 
launched  on  February  22,  1978  and  is  no  longer  operational.  Between 
February  1978  and  October  1985  there  were  ten  more  identical  satellites 
launched  among  which  only  one  is  still  operational.  From  February  1989  to 
October  1990  nine  more  vehicles  were  put  on  orbit  designated  as  type  Block 
II.  From  November  1990  to  March  1994  the  last  generation  of  fifteen  GPS 
satellites  designated  as  type  Block  IIA  were  launched  into  orbit.  The  twenty 
four  Block  II  and  Block  IIA  vehicles  are  those  which  constitute  the  full 
operational  GPS  constellation.  Three  of  them  are  on-orbit  spares  (Fig. 2. 2). 

The  information  provided  by  the  satellites  to  the  users  is  sent  to  earth 
by  the  means  of  two  L-band  carrier  signals,  LI  (1575.42  MHz),  and  L2 
(1227.6  MHz).  On  these  carrier  frequencies  are  superimposed  two  different 
binary  codes,  the  C/A  code  (which  stands  for  Coarse  Acquisition),  and  the 
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P-code  (which  stands  for  Precision).  The  P-code  is  only  accessible  by  military 
users  and  is  protected  by  encryption  so  that  full  positioning  accuracy  is  denied 
to  unauthorized  users.  Although  all  satellites  are  transmitting  on  the  same 
frequency,  they  are  assigned  their  own  unique  C/A  and  P  codes  so  that  the 
GPS  receivers  can  distinguish  between  them. 

In  an  ideal  world,  the  satellites  should  stay  right  on  their  orbits  and 
continue  to  rotate  around  the  earth  in  accordance  with  the  Keplerian  laws. 
Unfortunately  this  is  not  the  case  since  their  orbits  are  disturbed  by  various 
forces.  The  most  important  ones  are  the  gravitational  perturbation  of  the 
earth's  second  and  fourth  zonal  harmonic,  solar  and  lunar  gravity,  solar 
radiation  pressure,  and  various  gravity  anomalies.  Therefore,  there  exists  the 
need  for  a  control  center  that  closely  follows  each  satellite's  behavior  and  take 
the  required  corrective  actions  when  necessary.  This  is  exactly  the  task  of  the 
control  segment. 

B.  THE  CONTROL  SEGMENT 

The  control  segment  has  the  sole  responsibility  to  make  sure  that  the 
GPS  satellites  are  in  their  proper  orbit  ,  functioning  correctly,  and  transmitting 
the  correct  values  of  the  navigational  parameters.  The  GPS  ground  network 
consists  of  five  active-tracking  ground  antennas  and  five  passive-tracking 
monitor  stations,  located  around  the  world. 

The  active-tracking  ground  antennas  actively  track  the  GPS  satellites, 
transmitting  commands  and  navigation  uploads,  and  recording  telemetry  over 
S-band  links.  The  passive  tracking  monitor  stations  passively  track  the  L-band 
signals  transmitted  by  the  satellites  to  determin  the  vehicle's  navigational  data. 

All  the  above  data  is  collected  at  the  Falcon  Air  Force  Base,  Colorado 
Springs,  Colorado,  where  the  master  control  station  of  the  GPS  control 
segment  is  located.  The  collected  data  is  used  as  an  input  to  a  Kalman  Filter 
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from  which  the  orbital  states  of  the  space  vehicles  can  be  determined.  New 
navigational  parameters  are  then  passed  to  the  satellites  via  the  S-band  radio 
links.  The  master  control  station  personnel  are  also  responsible  for 
maneuvering  the  satellites  to  keep  them  in  their  preassigned  orbits.  When 
satellite's  performance  is  inaccurate  or  a  mechanical  failure  has  occurred,  the 
vehicle  is  considered  "unhealthy"  and  a  special  warning  is  incorporated  in  its 
navigational  message  to  warn  the  GPS  users. 

With  the  whole  GPS  infrastructure  perfectly  working,  the  only 
component  that  remains  in  order  for  a  navigator  to  obtained  a  position  fix  is  a 
GPS  receiver  which  will  receive,  decode,  and  process  the  navigational  data 
transmitted  by  the  satellites.  The  user's  end  of  the  GPS,  the  GPS  receivers,  is 
referred  to  as  the  user  segment. 


C.  THE  USER  SEGMENT 

The  user  segment  is  responsible  for  obtaining  the  navigational  signals 
provided  by  the  satellites  and  extracting  the  precise  values  of  three 
dimensional  position,  velocity,  and  time.  There  are  several  types  of  receivers. 
Their  classification  is  usually  by  how  many  channels  they  have. 

Each  separate  channel  is  a  radio  receiver  that  can  track  one  or  more 
satellites.  If  it  tracks  one  satellite,  it  is  full  time  dedicated  to  that  one  signal. 
If  it  tracks  more  than  one  satellite,  it  has  to  use  time  sharing  technique,  that 
is,  tracking  each  satellite  sequentially  for  a  specified  amount  of  time.  The 
time  sharing  technique  yields  poorer  results  and  it  was  used  by  the  very  first 
receivers  built.  A  typical  number  of  separate  channels  for  a  modern  receiver  is 
six  to  twelve. 

There  are  two  major  observables  that  can  be  used  by  a  receiver  in  order 
to  determine  its  position.  The  first  is  the  pseudorange  and  the  second  is  the 
carrier  phase.  Each  satellite  timetags  its  transmissions  so  that  when  they  are 
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received  by  the  receiver,  the  latter  knows  the  transmission  time.  The  receiver 
also  knows  the  time  that  the  transmission  was  received  from  its  internal  clock. 
The  receiver  software  then  extracts  the  time  difference  between  transmission 
and  reception,  that  is  the  time  it  takes  the  signal  to  travel  from  satellite  to  the 
receiver.  Multiplying  this  time  difference  by  the  speed  of  light,  the  actual 
distance  between  the  satellite  and  the  receiver  can  be  calculated. 

Onboard  the  satellites,  extremely  precise  and  expensive  atomic  clocks 
keep  track  of  GPS  time.  On  the  other  end,  the  receivers  carry  relatively  cheap 
clocks  which  are  not  very  accurate.  A  one  billionth  of  a  second  uncertainty  in 
the  time  difference  measurement  multiplied  by  the  speed  of  light  yields  a  range 
uncertainty  of  one  foot.  So  the  receiver  clock  inaccuracy  is  an  error  that  has 
to  be  taken  care  of  during  the  range  determination.  The  calculated  range  is 
called  pseudorange  since  it  is  not  the  actual  range  due  to  the  above  error. 

By  decoding  the  satellite  message,  the  GPS  receiver  can  also  obtain  the 
satellite's  position  (ephemeris)  in  earth-centered  earth-fixed  coordinates.  By 
doing  this  for  four  satellites  it  can  solve  the  following  set  of  equations  and 
determine  its  position  coordinates  x,  y  and  z,  along  with  the  receiver  clock 
error.  All  position  coordinates  x,y,z  are  given  in  earth-centered  earth-fixed 
coordinate  system: 


Ri  =  Jfa  ~  *)2  +  CVi  “JO2  +  (?i  ~  +c  *  dt 

R2  =  J(x 2  -  x)2  +  (>2  ~y)2  +  O2  -  z)2  +c  *  dt 

R^  =  J(x 3  - x)2  +  (y3  -y)2  +  (Zi  - z)2  +c  *  dt 

R4  =  J~(x 4  - x)2  +  (y4  -y)2  +  (z4  - z)2  +c  *  dt  (2.1) 
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where  Rt  is  the  pseudoranges,  dt  is  the  receiver  clock  error  and  c  is  the  speed 
of  light.  The  subscripts  denote  quantities  related  with  each  of  the  four 
satellites. 

Next,  the  position  fix  of  the  receiver  obtained  in  earth-centered 
earth-fixed  coordinates  must  be  transformed  to  the  user's  preferable 
coordinate  system.  It  should  be  noted  that  the  above  equations  (2.1)  represent 
a  very  basic  problem  formulation.  In  real  life,  the  receiver's  software  has  to 
take  care  of  many  other  factors  that  are  involved  in  the  problem  solution.  In 
fact  many  of  the  problem  parameters  are  obtained  as  states  of  a  Kalman  filter, 
rather  than  straightforward  algebraic  solutions. 

Use  of  the  carrier  phase  observable  is  a  relatively  new  technique.  When 
a  GPS  receiver  acquires  the  signal  of  a  satellite,  it  can  measure  the  fractional 
part  of  a  single  cycle  of  the  carrier  wave.  As  every  complete  cycle  represents 
distance  equal  to  the  wavelength  of  the  carrier  wave,  (20  cm  for  the  LI 
frequency),  the  carrier  phase  observable  can  be  translated  to  range  information 
from  the  particular  satellite.  Of  course  we  cannot  determine  a  pseudorange 
only  from  carrier  phase  measurements  because  it  is  impossible  to  know  how 
many  complete  cycles  are  there  between  the  satellite  and  the  receiver  without 
any  other  information.  What  we  can  do  is  track  the  carrier  phase  changes,  and 
feed  them  into  the  Kalman  filter  mentioned  above  to  "smooth"  pseudorange 
estimates. 

To  determine  its  velocity,  the  receiver  also  monitors  the  carrier  wave. 
This  time,  the  Doppler  shift  frequency  from  each  tracked  satellite's  carrier 
wave  is  monitored.  The  relative  velocities  with  respect  to  the  satellites  are 
determined,  and  the  receiver's  velocity,  resolved  on  the  three  dimensional 
coordinate  system,  is  computed  from  the  known  satellite  positions.  The  GPS 
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receivers  do  not  calculate  velocity  by  working  out  a  time-distance  problem 
between  two  consecutive  position  fixes  as  a  common  misconception  suggests. 
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III.  USING  THE  GPS  POSITIONING  INFORMATION 


There  are  two  approaches  with  respect  to  what  form  of  GPS 
information  can  we  use  to  obtain  precise  positioning.  The  first,  and  most 
trivial,  is  to  use  the  readily  available  position  fix  coordinates  (in  whatever 
coordinate  system)  that  the  receiver  is  providing  after  processing  the  raw 
GPS  observables,  i.e.  the  pseudoranges  and  the  carrier  phase.  In  the  second 
approach,  the  user  develops  his  own  software  that  processes  the  raw 
observables  which  are  available  as  outputs  of  many  GPS  receivers  to  obtain  his 
application  specific  information. 

In  our  case,  we  are  using  two  OEM  (original  equipment  for 
manufacturers)  class  receiver  modules  type  PVT-6  made  by  Motorola.  One  of 
them  will  be  placed  on  the  UAV  while  the  other  one  will  be  stationed  on  the 
ground  and  used  as  a  reference  station  providing  differential  corrections  for 
the  operational  area. 

Both  ways  are  evaluated  here  with  respect  to  our  specific  Archytas 
application. 

A.  USING  THE  POSITION  FIX  OUTPUTS 

The  Motorola  PVT-6  receivers  use  three  coordinate  systems  in  order  to 
determine  their  position  fix  and  their  velocity.  These  are: 

1.  Geodetic  Latitude,  Longitude,  Height. 

The  first  is  the  well  known  Geodetic  Latitude,  Longitude  and  Height. 
The  geodetic  latitude  of  a  point  is  the  angle  from  the  equatorial  plane  to  the 
vertical  direction  of  a  line  normal  to  the  reference  ellipsoid.  The  geodetic 
longitude  of  a  point  is  the  angle  between  the  Prime  Meridian  plane  and  the 
plane  passing  through  the  point,  both  planes  being  perpendicular  to  the 
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equatorial  plane.  The  geodetic  height  of  a  point  is  the  vertical  distance,  (with 
respect  to  the  reference  ellipsoid),  from  the  point  to  the  reference  ellipsoid 
itself. 

The  above  three  coordinates  can  have  different  values  depending  on  the 
reference  ellipsoid  and  geodetic  datum  that  is  used  to  define  the  coordinate 
system.  The  reference  ellipsoids  are  ellipsoidal  models  of  the  shape  of  the 
earth.  They  are  defined  by  their  semi-major  axis,  (equatorial  radius),  and  their 
inverse  flattening  parameter.  The  most  accurate  of  them  is  the  WGS-84  which 
models  the  shape  of  the  earth  over  a  smooth  averaged  sea  surface  with  an 
accuracy  of  about  one  hundred  meters  [Ref.  9], 

The  reference  systems  describing  the  size  and  shape  of  the  earth  are 
defined  by  the  geodetic  datums.  The  geodetic  datums  obtained  from  a 
reference  ellipsoid  and  the  relationship  between  the  ellipsoid  and  a  point  on 
the  topographic  surface  established  as  the  origin  of  the  datum.  This 
relationship  can  be  defined  by  six  quantities  generally,  (but  not  necessarily), 
which  are  the  geodetic  latitude,  longitude  and  the  height  of  the  origin,  the  two 
components  of  the  deflection  of  the  vertical  at  the  origin,  and  the  geodetic 
azimuth  of  a  line  from  the  origin  to  some  other  point  [Ref.  9], 

There  are  many  different  datums  used  around  the  world  so  that  one 
point  on  the  surface  of  the  earth  can  be  described  by  different  set  of  values  for 
latitude,  longitude  and  height,  depending  in  which  datum  are  the  coordinates 
expressed.  Relating  geodetic  coordinates  with  the  wrong  datum,  can  result  in 
a  position  error  of  hundreds  of  meters.  The  most  recent  and  accurate  of  all 
the  datums  is  the  WGS-84  (World  Geodetic  System  -  1984),  which  is  used  as  a 
common  ground  in  order  to  unify  all  the  different  datums  used  around  the 
world.  The  WGS-84  has  been  used  by  the  GPS  since  1987. 
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Finally,  we  should  note  that  the  receiver  outputs  its  velocity  as  a  vector 
with  magnitude  expressed  in  meters  per  second  and  direction  expressed  in 
degrees  with  respect  to  the  true  (WGS-84)  north. 

2.  Earth  Centered  Earth  Fixed  Coordinate  System  (ECEF) 

This  coordinate  system  is  used  by  our  Motorola  GPS  receivers  in  order 
to  alternatively  express  three  dimensional  position.  This  is  a  Cartesian 
coordinate  system  with  respect  to  the  center  of  mass  of  the  reference  ellipsoid 
where: 

•  The  Z-axis  points  towards  the  North  Pole. 

•  The  X-axis  is  defined  by  the  intersection  of  the  plane  defined  by  the  prime 
meridian  and  the  equatorial  plane  . 

•  The  Y-axis  completes  a  right  handed  orthogonal  system  by  a  plane  90  east  of 
the  X-axis  and  its  intersection  with  the  equator. 

Again  here  the  reference  ellipsoid  is  the  WGS-84.  The  velocity  is  not 
expressed  in  the  ECEF  coordinate  system,  however  it  is  expressed  in  the 
tangent  plane  coordinate  system. 

3.  Tangent  Plane  (Local  Geodetic)  Cartesian  Coordinate  System. 

This  coordinate  system  can  be  defined  at  any  point  of  the  surface  of  the 
'  earth  by  considering  a  plane  tangent  to  the  reference  ellipsoid  at  that  point 
and: 

•  The  X-axis  being  on  the  plane  and  pointing  towards  true  East. 

•  The  Y-axis  being  on  the  same  plane  and  pointing  towards  true  North. 

•  The  Z-axis  being  perpendicular  to  the  tangent  plane  and  pointing  towards  the 
center  of  the  ellipsoid. 

All  the  axis  originate  from  the  common  point  of  the  ellipsoid  and  the  tangent 
plane. 

The  tangent  plane  system  is  used  by  the  Motorola  receivers  in  order  to 
provide  an  alternate  expression  for  the  velocity.  The  velocity  is  expressed  by 
means  of  North,  East,  and  Up  components.  It  should  be  noted  that  the  Up 
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component  is  positive  when  it  is  directed  away  from  the  center  of  the 
reference  ellipsoid,  i.e.  along  the  usual  upward  direction. 

4.  Pros  And  Cons  Of  Using  The  Position  Fix  Outputs 

The  easiest  way  to  obtain  position  and  velocity  data  for  Archytas  is  to 
use  the  readily  available  position  and  velocity  information  in  the  format 
discussed  above.  It  also  should  be  noted  that,  since  the  velocity  is  expressed 
in  the  local  tangent  coordinate  system,  the  integration  between  the  GPS  and 
the  inertial  measurement  unit  (IMU)  data  is  very  easy  since  the  latter  also  uses 
the  same  coordinate  system  not  just  to  express  velocity,  but  also  acceleration 
and  position.  The  IMU  data  is  used  by  the  Archyta’s  flight  controller  as  the 
primary  information  to  solve  the  bird's  stability  problem. 

To  take  advantage  of  the  Differential  Correction  technique,  we  have  to 
use  two  GPS  receivers  simultaneously.  The  first  one  will  be  placed  on 
Archytas  and  will  transmit  position  and  velocity  to  the  flight  control  computer 
on  the  ground  by  a  radio  link.  The  second  GPS  receiver  will  be  on  the 
ground  functioning  as  a  reference  station  that  will  generate  differential 
corrections  for  the  GPS  raw  observables  (pseudorange  and  pseudorange 
rates).  These  corrections  will  then  be  uploaded  in  real  time  to  the  vehicle's 
GPS  receiver  by  means  of  another  radio  link,  thus  providing  the  full 
differential  capability. 

There  are  two  choices  for  setting  up  the  radio  link  system.  The  need  of 
establishing  a  two  way  communication  system  is  obvious.  This  can  be  done 
either  in  full  or  half  duplex. 

For  the  half  duplex  mode,  we  need  two  radio  link  transceivers,  one  on 
the  vehicle  and  another  on  the  ground.  Both  transceivers  will  transmit  on  the 
same  frequency.  Next  we  need  two  computers,  again  one  on  the  vehicle  and 
one  on  the  ground.  These  computers  will  play  the  role  of  the  "traffic  cops"  for 
the  two  transceivers.  Each  computer  will  control  its  assigned  transceiver  and 
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will  exchange  the  proper  messages  with  the  other  computer  via  the  radio  link 
to  ensure  that  when  one  transceiver  is  transmitting  the  other  is  ready  to 
receive,  and  also  that  the  two  transceivers  are  not  transmitting  on  the  same 
time,  which  would  result  in  loss  of  data. 

This  setup  is  has  a  major  drawback.  The  transceiver  controlled  by 
computer  onboard  the  vehicle  would  result  in  extra  weight  and  extra  power 
consumption.  Therefore,  the  half  duplex  method  was  abandoned  and  the  full 
duplex  method  examined  instead. 

The  full  duplex  mode  is  straightforward  to  implement.  The  only 
hardware  needed  is  two  full  duplex  capable  transceivers  that  will  be  directly 
communicating  with  the  RS-232  port  of  the  GPS  receivers.  Two  separate 
frequencies  will  support  the  two  way  communication  so  that  the  data  flow  will 
be  in  real  time  and  uninterrupted,  both  from  the  Archyta's  GPS  receiver  to  the 
flight  controller,  and  from  the  reference  station  GPS  receiver  to  the  Archyta's 
GPS  receiver. 

The  only  drawback  of  this  method  is  the  cost  associated  with  the 
purchase  of  the  full  duplex  capable  transceivers.  However,  these  were  not 
available  during  this  thesis  experimental  work.  To  overcome  this  problem,  the 
second  more  elaborated  approach  of  using  the  GPS  raw  observables  was 
examined. 

B.  USING  THE  RAW  GPS  OBSERVABLES  OUTPUT 

With  this  approach,  the  raw  GPS  observables  (pseudoranges  only  in  our 
case)  were  used  in  order  to  obtain  position  fix  information  for  our  vehicle.  By 
computing  the  pseudoranges  from  at  least  four  satellites  tracked  by  the  GPS 
receiver  and  by  knowing  the  satellites  exact  position  in  ECEF  coordinates,  the 
position  equations  (2.1)  can  be  solved  yielding  the  receiver's  position  in  ECEF 
coordinates.  The  parameters  required  to  solve  (2.1)  are  examined  next. 
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1.  The  Ephemeris  Satellite  Message 

As  discussed  in  Chapter  II,  many  environmental  factors,  some 
predictable  and  other  not,  tend  to  "derail"  the  satellites  from  their  commanded 
orbits.  For  the  GPS  receivers  to  solve  the  position  equations  (2.1),  the 
satellites  positions  are  continuously  transmitted  as  part  of  the  GPS 
navigational  message.  Each  space  vehicle  transmits  its  own  ephemeris,  that  is 
the  part  of  the  message  that  describes  its  position,  consisting  of  sixteen 
constants.  These  sixteen  constants  are: 


•  M0, 

Mean  anomaly 

*  », 

Mean  motion  difference 

*  Ja , 

Square  root  of  semi-major  axis 

'  ®o. 

Right  ascension 

’  jo. 

Inclination 

Argument  of  perigee 

•  —0 

dr  ’ 

Rate  of  right  ascension 

.  ±i 

dt 

Rate  of  inclination 

Cuc,Cus, 

Correction  terms  to  arg.  of  latitude 

•  CrcCrs, 

Correction  terms  to  orbital  radius 

•  Cic,Cis, 

Correction  terms  to  inclination 

•  to. 

Ephemeris  reference  time 

These  constants  are  contained  in  the  subframes  two  and  three  of  the 
50-bit  per  second  bitstream  superimposed  on  the  carrier  frequency  of  the  GPS 
navigation  message.  They  are  estimated  and  uploaded  daily  by  the  master 
control  station  at  the  Falcon  Air  Force  Base  for  each  GPS  satellite,  and  then 
are  retransmitted  to  the  users  of  the  system  worldwide. 

The  exact  position  of  the  above  constants  in  the  satellite  data  bitstream 
is  described  by  the  Interface  Control  Document  ICD-200  which  is  published 
by  the  GPS  Joint  Program  Office,  Los  Angeles  Air  Force  Base,  Los  Angeles. 
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To  compute  the  satellites  position  in  ECEF  coordinates  from  the 
ephemeris  constants,  a  simple  set  of  algebraic  and  trigonometric  equations  has 
to  be  solved. 

It  should  be  noted  here  that  the  ephemeris  message  is  not  the  only  GPS 
message  containing  information  about  satellite  positions.  The  almanac 
message  also  contains  positions,  although  not  as  accurate  as  in  the  ephemeris 
message.  Each  satellite  in  its  almanac,  transmits  all  the  other  satellite's 
position.  However  these  positions  are  not  used  for  position  fix  estimation. 
When  the  receiver  aquires  one  satellite,  then  it  uses  the  almanac  information  to 
acquire  the  rest  that  are  visible  in  its  area. 

2.  The  Satellite  Pseudoranges 

The  satellite  pseudoranges  are  computed  by  multiplying  the  speed  of 
light  by  the  time  that  the  signal  traveled  from  the  satellite  to  the  GPS  receiver. 
The  travel  time  is  found  by  subtracting  the  time  that  the  signal  was  received, 
from  the  time  it  was  transmitted  from  the  satellite.  The  latter  time  is  provided 
by  the  GPS  message,  while  the  former  is  obtained  from  the  receiver's  internal 
clock. 

3.  Evaluation  Of  Using  Raw  Observables  Processing  Approach 

By  now  we  have  determined  all  the  required  parameters  in  order  to 
solve  the  equations  (2.1)  and  extract  the  receiver's  ECEF  coordinates.  The 
solution  can  be  worked  out  by  a  user  developed  software  executed  on  the 
flight  control  computer  of  the  Archytas,  which  is  located  on  the  ground  and 
communicates  with  the  vehicle  via  a  radio  link. 

Why  would  anyone  use  this  elaborate  approach  to  determine  the 
vehicle's  position  when  the  latter  is  readily  available  as  a  GPS  receiver  output? 
The  answer  is  because  this  way  a  simpler  radio  link  in  simplex  mode  would  be 
required,  resulting  in  weight  and  cost  savings.  The  GPS  receiver  onboard  the 
vehicle  would  be  sending  to  the  flight  controller  the  satellite  signal 
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transmission  time,  the  time  that  this  signal  was  received,  and  the  ephemeris 
data.  The  flight  controller  would  compute  the  pseudoranges  and  the  satellite 
positions  as  described  above.  The  pseudorange  corrections  would  be  fed  to 
the  flight  controller  by  the  other  GPS  receiver  stationed  on  the  ground  and 
used  as  a  reference  station  by  means  of  wired  connections.  Then  the 
pseudoranges  would  be  corrected  and  equations  (2.1)  could  be  solved  yielding 
differentially  corrected  positions. 

Although  this  approach  sounded  promising,  it  was  abandoned  for  the 
following  reasons: 

•  The  ephemeris  message  is  very  complicated  and  hard  to  decode. 

*  Although  satellite  pseudoranges  can  be  algebraically  computed,  the  solutions 
incorporate  a  large  number  of  errors.  Some  of  them  are  associated  with  time 
delays  that  are  difficult  to  model,  and  others  with  the  presence  of  relativistic 
effects  during  the  transmission  of  the  signal  by  the  satellite.  The  actual  receiver 
software  "smooth "  the  pseudoranges  by  using  Kalman  filtering  technique  and 
the  carrier  phase  observables. 

♦  The  receiver's  velocity  cannot  be  determined  because  the  Doppler  frequency 
shift  associated  with  each  satellite  is  not  available  as  a  GPS  receiver  output. 

As  a  result  of  all  the  above  considerations,  it  was  decided  that  the  flight 
controller  of  the  vehicle  would  be  given  readily  available  position  fix  and 
velocity  information  from  the  GPS  receiver,  while  the  differential  setup  would 
be  implemented  using  a  full  duplex  radio  link  as  discussed  earlier  in  this 
chapter.  Because  a  full  duplex  radio  link  was  not  available  during  the 
experimental  work,  wired  connections  have  been  used  to  test  the  whole  setup, 
assuming  that  the  wireless  communication  is  a  task  easily  achievable  using  the 
proper  commercial  equipment. 

Finally  the  software  that  computes  the  satellite  pseudoranges  and 
pseudorange  rates  was  also  developed  in  order  to  facilitate  future  work  on  the 
subject. 
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IV.  HARDWARE  DESCRIPTION 


A.  MOTOROLA  PVT-6  RECEIVER  DESCRIPTION 

The  Motorola  PVT-6  GPS  receiver  belongs  to  the  large  class  of 
receivers  designated  as  OEM  receiver  modules.  OEM  stands  for  Original 
Equipment  for  Manufacturers  and  means  that  this  receiver  is  not  readily  usable 
by  itself,  but  designed  to  be  used  as  a  part  of  a  larger  group  of  devices.  The 
first  thing  to  be  noted  is  that  their  is  no  display  screen  or  keyboard.  This 
receiver  is  configured,  controlled  and  read  through  another  computer  which 
acts  as  the  host  equipment  and  communicates  with  the  PVT-6  through  a 
standard  RS-232C  interface. 

Its  generalized  outputs  are  position,  velocity,  time,  and  satellite 
tracking  status.  It  is  capable  of  supporting  land,  air,  and  marine  applications. 
Generally  the  requirements  that  distinguish  each  of  the  above  applications  are 
the  Time  to  First  Fix  (TTFF),  the  reacquisition  time,  and  the  dynamic 
positioning  requirements. 

The  TTFF  defines  the  time  before  the  first  fix  after  the  receiver  is 
powered  up.  Reacquisition  time  is  the  time  that  the  receiver  needs  in  order  to 
recompute  its  position,  after  the  signal  from  one  or  more  satellites  tracked  is 
lost.  Dynamic  Positioning  is  the  ability  of  the  receiver  to  keep  track  of  the 
vehicle's  position  while  experiencing  large  accelerations  or  deccelerations. 

The  above  requirements  become  more  stringent  for  marine  and  air 
applications.  The  PVT-6  receiver,  partly  due  to  the  six  parallel  channels  (each 
one  dedicated  to  track  only  one  satellite)  that  it  has,  can  qualify  for  all  the 
above  types  of  applications. 

There  are  five  factory  options  for  specialized  applications.  These  are 
designated  as  A,B,C,D,E.  Our  receivers  are  option  ABC  which  gives  us  full 
operational  capability,  such  as  one  Pulse  Per  Second  output  (1PPS),  Real  Time 
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Differential  (RTD)  GPS  capability,  and  satellite  Pseudorange/Carrier  Phase 
data. 

The  internal  components  of  the  PVT-6  receiver  are  shown  in  Fig.4.1. 
The  module  receives  the  LI  frequency  GPS  signal,  thus  obtaining  the  C/A 
code  (Coarse/ Aquisition).  The  code  tracking  is  carrier  aided.  A  low  profile, 
micro-strip  patch  antenna  is  used  to  track  the  LI  frequency.  The  antenna  is 
shown  in  Fig. 4. 2,  together  with  its  gain  pattern.  It  is  obvious  that  the  gain  is 
maximum  directly  overhead  while  is  diminishing  at  low  elevations.  This  is  in 
accordance  with  the  nature  of  the  GPS  signal,  which  aquires  large  propagation 
errors  through  the  atmosphere  when  a  satellite  "sees"  a  receiver  through  a  low 
elevation  angle.  In  the  antenna  module  are  a  narrow  band  pass  filter  and  a 
preamplifier.  The  preamplifier  is  powered  with  +5V  DC  through  the  coaxial 
interconnecting  cable,  which  is  primarily  used  for  the  signal  transmission  to 
the  receiver  module.  [Ref. 2] 

Before  the  receiver  module,  the  signal  enters  the  RF  Down  Converter 
which  converts  it  into  an  intermediate  frequency  (IF)  signal.  It  then  passes 
through  the  6-channel  code  and  carrier  correlator  section  where  the  IF  signal 
is  converted  to  a  digital  sequence  prior  to  channel  separation.  The  conversion 
is  executed  by  a  single,  high  speed  analog  to  digital  converter.  The  resulting 
digitized  IF  signal  is  routed  to  the  digital  signal  processor  where  it  is  split  into 
six  separate  channels  for  code  correlation,  filtering,  code  tracking,  and  signal 
detection.  [Ref.  2] 

The  next  station  is  the  position  microprocessor.  This  is  the  "brain"  of 
the  receiver  as  it  controls  its  operating  modes  and  processes  all  the  satellite 
data  in  order  to  compute  position,  velocity,  and  time.  Here  also  is  the 
required  interface  to  the  RS232  serial  port  used  for  full-duplex,  asynchronous 
data  communication  with  the  host  equipment.  [Ref.2] 
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The  PVT-6  is  characterized  as  Data  Communications  Equipment  (DCE), 
while  the  host  equipment  is  characterized  as  Data  Terminal  Equipment  (DTE), 
in  accordance  with  the  RS-232  communications  standard. 

The  PVT's  serial  port  is  shown  in  Fig. 4. 3.  Out  of  the  ten  available  pins, 
the  only  ones  dealing  with  RS-232  type  signals  are  pins  eight,  nine  and  ten. 
These  are  designated  as  transmit(TXD),  receive  (RXD),  and  ground  or  return 
(RTN)  respectively.  The  host  equipment  has  to  have  a  serial  channel 
completely  devoted  in  monitoring  the  PVT-6,  as  the  software  or  hardware 
flow  control  between  the  two  devices  is  obviously  not  possible. 

The  PVT-6  can  obtain  uninterrupted  navigational  solutions  when 
its  velocity  is  less  than  515  m/s  and  is  not  experiencing  accelerations  more 
than  2g.  If  the  acceleration  is  less  than  4g  it  will  maintain  lock  on  satellites. 
All  these  limits  are  more  than  adequate  for  our  application. 

Finally  we  note  that  the  module  is  powered  either  with  a  5V  DC 
regulated  voltage  or  with  a  12V  DC  unregulated  voltage.  The  power 
consumption  in  any  case  does  not  exceed  1.8  watts.  In  Figs. 4. 4  and  4.5,  two 
other  views  of  the  receiver  are  shown.  In  Table  4.1,  the  general  product 
specifications  are  listed. 


B.  ARCHYTA'S  FLIGHT  CONTROLLER 

The  processor  used  to  control  Archytas  is  a  TMS320C30  type  digital 
signal  processor  manufactured  by  Texas  Instruments.  It  has  a  40-ns  cycle  time 
enabling  it  to  perform  60  million  floating  point  operations  per  second 
(MFLOPS),  and  30  million  instructions  per  second  (MIPS),  a  performance 
previously  typical  of  a  supercomputer.  [Ref.  4] 

The  C30  processor  board  is  hosted  on  a  IBM  PC/AT  computer,  the 
AC100  Model  C30.  The  basic  AC100  Model  C30  PC  hardware  consists  of  the 
TMS320C30  CPU  card,  a  DSPFLEX  carrier  board,  and  an  ethernet  adapter. 
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The  DSPFLEX  board,  (Fig. 4. 6),  is  a  specialized  full  length  ISA  real  time 
input-output  card  which  functions  as  the  interface  for  the  C30  to  communicate 
with  four  GreenSpring  Computers  IndustyPack  (IP),  or  IP  compatible, 
input-output  modules.  The  IP  modules  are  the  interface  of  the  controller  with 
the  "outside  world".  Up  to  four  DSPFLEX  boards  can  be  installed.  Each 
board  labels  its  four  positions  for  IP  modules  as  A,B,C,D  (Fig. 4. 7).  The  IP 
modules  are  accordingly  labeled  1,2, 3, 4  corresponding  to  the  above  positions. 
This  is  particularly  important,  since  the  modules  are  referred  to  by  the 
software  using  these  numbers.  [Ref. 5] 

Many  types  of  IP  modules  are  available.  A  serial  one  is  used  to 
interface  the  GPS  receiver  with  the  C30  and  is  assigned  the  module  number  3, 
(position  C  on  the  DSPFLEX  board).  It  provides  two  channels  of  multimode 
serial  communication  in  both  the  RS-232C  and  RS-422  standards.  There  are 
two  physical  serial  channels  on  each  IP  serial  module,  named  channelA  and 
channelB,  communicating  via  a  50-pin  connector.  In  our  case,  that  means  the 
C30  can  "read"  two  GPS  receivers  at  the  same  time.  The  pin-out 
configuration  of  the  IP  serial  module  is  shown  in  Fig. 4. 8.  [Ref.5] 

The  complete  C30  system  also  includes  a  UNIX  workstation.  The 
workstation  is  used  to  run  specific  software  packages  such  as  Integrated 
System's  SystemBuild  design  and  analysis  software,  and  AutoCode  automatic 
code  generator.  These  allow  for  the  various  algorithms  to  be  developed  in 
block  diagram  form,  then  transformed  into  G  code,  and  executed  in  real  time 
on  the  C30  DSP  board.  During  real  time  operation,  the  UNIX  workstation  can 
be  used  to  acquire  data  and  graphically  interact  with  the  executing  application. 
The  complete  hardware  setup  is  shown  in  Fig. 4. 9.  [Ref.5] 
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V.  INTERFACING  THE  GPS  RECEIVER  WITH  THE  AC100 
MODEL  C30  FLIGHT  CONTROLLER 

A.AC100  MODEL  DESCRIPTION  AND  FUNCTIONALITY 

To  interface  the  GPS  receiver  with  the  AC100  Model  C30  controller,  a 
simple  block  diagram  description  of  the  system  had  to  be  built  using  the 
AC  100  software  package  installed  on  the  UNIX  workstation.  Then  this  model 
was  converted  into  an  executable  C  code  file  and  downloaded  on  the  C30  for 
execution.  Any  manipulation  of  the  GPS  receiver  data  is  unnecessary  at  this 
point  since  we  are  only  interested  in  simply  reading  it  and  verify  its 
correctness.  Thus,  a  unity  gain  block  was  developed  in  SystemBuild  (Fig. 5.1). 

The  general  idea  is  that  the  GPS  data  is  transmitted  from  the  GPS 
receiver's  RS-232C  serial  port  (by  wired  connections,  or  wireless  by  radio 
link)  and  is  received  by  the  IP-Serial  module  (channelA  or  channelB)  of  the 
C30  controller.  Then  it  is  processed  as  specified  in  the  file  "user  ser.c", 
which  is  the  user  interface  to  the  IP-Serial  Device  Driver.  After  data  is 
decoded,  it  is  displayed  on  the  UNIX  workstation  using  a  graphical  user 
interface  (GUI). 

The  GUI  is  built  by  invoking  the  Interactive  Animation  Builder.  Four 
icons  are  built  in  order  to  have  a  better  representation  of  the  GPS  data.  Each 
icon  displays  the  variables  originating  from  a  specific  GPS  receiver  message 
type.  The  first  three  icons  show  the  data  from  the  GPS  receiver  which  is 
supposed  to  be  placed  on  Archytas,  while  the  fourth  shows  data  from  the 
differential  base  station. 

The  first  icon,  (Fig. 5. 2),  displays  the  receiver's  Latitude,  longitude, 
Height-msl  (mean  sea  level),  Height-GPS  (with  respect  to  the  reference 
ellipsoid,  in  our  case  the  WGS-84),  Velocity  and  heading.  The  second  icon, 
(Fig. 5. 3),  displays  the  ECEF  coordinates  X,Y,Z,  of  the  receiver  plus  its  three 
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velocity  components  in  the  Local  Tangent  Plane  coordinates,  i.e.  North,  East, 
and  Up.  The  third  icon,  (Fig. 5. 4),  displays  the  Satellite  Vehicle  Identification 
Number  (SVIN)  of  the  satellites  tracked,  their  tracking  mode  byte,  their  GPS 
message  transmission  time,  the  extracted  pseudoranges  and  pseudorange  rates 
of  each,  and  finally  the  receiver's  GPS  local  time.  The  fourth  icon,  (Fig. 5. 5) 
displays  the  SVIN  tracked  by  the  reference  station,  the  GPS  time  reference, 
and  the  pseudorange,  pseudorange  correction  and  the  issue  of  ephemeris  data 
for  each. 

In  each  icon,  two  "checksum"  bytes  are  also  present.  These  represent 
the  internal  checksum  of  the  GPS  message  and  the  computed  one  from  the 
userser.c  file,  which  are  used  to  check  the  received  data's  integrity. 

It  should  be  noted  that  the  only  thing  executed  by  the  TMS320C30  DSP 
processor  while  the  model  is  running  in  real  time,  is  the  executable  image  of 
the  unity  gain  with  seventy  seven  input  variables  provided  by  the  IP-Serial 
Device  Driver  and  outputs  the  same  seventy  seven  variables. 

An  important  part  of  this  thesis  was  to  develop  and  test  the  user  ser.c 
user  interface  file,  because  therein  the  actual  decoding  of  the  GPS  receiver 
message  takes  place.  This  message  is  then  passed  in  a  usable  format  to  the 
above  mentioned  AC  100  model.  For  this  reason,  user  ser.c  is  discussed  next 
together  with  a  receiver  binary  message  examination. 


B.  PVT-6  GPS  RECEIVER  OUTPUT  MESSAGE 

As  discussed  earlier  the  receiver  data  is  routed  to  the  host  equipment 
through  a  RS-232C  serial  port.  For  flexibility  Motorola  has  made  available 
three  interface  protocols  for  the  PVT-6.  These  are  the  Motorola  Proprietary 
Binary  Format,  the  NMEA-0813,  and  the  LORAN  emulation  format.  The 
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Motorola  Proprietary  Format  is  used  throughout  this  thesis,  because  of  its 
ease  of  use  and  its  unrestricted  access  to  all  the  receiver's  outputs. 

1.  Motorola  Binary  Format  Description 

In  this  format,  the  GPS  receiver  messages  consist  of  a  number  of  binary 
characters.  All  the  messages  start  with  two  characters  (hex40).  The  next 
two  characters,  (one  byte  each),  are  an  upper  or  lower  case  letter  denoting  the 
type  of  the  message,  i.e.  the  particular  structure  and  format  of  the  remaining 
binary  data.  Then  come  the  bytes  containing  the  information  carried  by  the 
message.  The  last  three  bytes  are  always  the  checksum  followed  by  a  carriage 
return  <CR>  and  a  line  feed  <LF>,  denoting  the  end  of  the  message.  The 
checksum  is  the  exclusive-or  of  all  the  message  bytes  after  the  last  and 
before  the  checksum  itself.  [Ref.  2] 

The  above  format  is  valid  for  both  input  and  output  receiver  messages. 
In  the  case  of  the  input  receiver  messages,  the  user  is  responsible  for  creating 
the  correct  bytestream  taking  care  of  the  message  format  and  the  checksum. 
The  incoming  messages  to  the  receiver  are  placed  in  a  buffer  which  is  serviced 
once  per  second  and  is  2048  bytes  long. 

Both  input  and  output  messages  contain  data  that  is  interpreted  as 
unsigned  integers,  signed  integers,  or  floating  point  values.  It  is  the  user's 
responsibility  to  correctly  parse,  decode,  and  scale  the  data  bytestream  he 
receives  to  obtain  the  correct  results.  After  the  message  is  read,  a  checksum 
should  be  generated  in  order  to  check  if  the  data  have  been  correctly  received 
by  the  host  equipment.  The  structure  of  all  the  Motorola  Binary  Format 
messages,  is  contained  in  paragraph  4.7  of  Ref.2. 

The  basic  output  messages  can  be  selected  to  be  one-time  output 
(polled)  or  at  a  selected  update  rate  (continuous).  The  continuous  messages 
may  have  a  rate  of  once  per  second  to  once  every  255  seconds.  One  point  that 
has  to  be  considered,  in  the  case  of  multiple  continuous  messages,  is  that  the 
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receiver  can  output  only  750  bytes  per  second.  If  the  number  of  output  bytes 
per  second  is  greater  than  750,  then  the  messages  that  don't  fit  into  the  750 
byte  stream  will  be  rescheduled  for  the  next  output  cycle.  The  basic  output 
messages  are  shown  in  table  5.1. [Ref. 2] 

The  Motorola  binary  format  also  supports  differential  capability.  That 
means  that  the  pseudorange  and  pseudorange  rate  corrections  messages  can  be 
expressed  in  the  above  format  so  that  they  can  be  interchanged  between 
Motorola  receivers  operating  in  the  proprietary  format. 

The  industry  standard  format  for  the  exchange  of  differential 
corrections  between  electronic  devices  is  the  one  issued  by  the  Radio 
Technical  Commission  for  Maritime  Services  (RTCM)  under  the  designator 
RTCM  SC- 104.  This  format  can  also  be  decoded  from  the  receiver  when  the 
latter  is  operating  under  the  proprietary  protocol,  and  is  especially  useful 
when  the  receiver  is  communicating  with  a  receiver  of  different  make. 

A  typical  example  is  a  PVT-6  onboard  a  seagoing  vessel,  receiving 
differential  corrections  from  the  US  Coast  Guard  DGPS  coastal  stations, 
which  use  GPS  reference  receivers  manufactured  by  Ashtech,  Inc.  Table  5.2 
shows  the  receiver's  differential  capability  with  respect  to  the  I/O  protocol 
used. 

2.  The  NMEA-0813  Format 

The  National  Marine  Electronics  Association  (NMEA)  defines  the 
standard  type  of  messages  to  be  exchanged  between  electronic  navigation 
devices  via  the  RS-232C  serial  interface.  It  has  limited  output  messages.  This 
format  is  useful  only  when  our  receiver  needs  to  be  interfaced  with  devices 
using  it,  i.e.  an  autopilot,  so  it  will  not  be  examined  further. 
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3.  The  LORAN  Emulation  Format 

This  format  is  used  whenever  the  PVT-6  needs  to  replace  LORAN 
receivers  in  embedded  positioning  system  applications.  It  is  of  no  interest  in 
our  case. 


C.  THE  "USERSER.C"  USER  INTERFACE  FILE 

As  previously  stated,  this  file  is  the  most  essential  part  of  the  whole 
project,  because  it  carries  out  the  actual  parsing,  decoding,  and  verification  of 
the  GPS  messages.  It  is  included  in  the  basic  AC  100  software  package  as  a 
user  alterable  interface  template  to  the  IP-Serial  Device  Driver,  and  follows  a 
standard  modular  design.  There  are  three  main  functions  in  userser.c  that  the 
user  must  develop  to  suit  his  specific  application.  These  three  functions  are: 

1.  get_SERIAL_parameters 

2.  user_SERIAL_out 

3.  usersampleSERIALin 

In  the  following  paragraphs  our  specific  software  will  be  explained. 
The  program  listing  is  shown  in  the  Appendix  C.  Detailed  instructions  on  how 
to  use  these  functions  are  provided  in  pages  133-142  of  the  Ref. 5. 

1.  The  "get_SERIAL_parameters"  Function 

This  function  is  called  once  during  initialization  of  the  system.  It 
contains  the  user  specified  parameters  used  for  the  asynchronous  serial 
communication  through  the  IP-Serial  modules.  As  it  can  be  seen  from  the 
Appendix  C,  the  parameter  values  are  in  accordance  with  the  PVT-6  output, 
i.e.  parity  =  NONE,  baud_rate  =  9600,  s  top_bits  =  ONE, 
receive_data_size  =  8,  clock_mul tiplier  =  16. 


27 


2.  The  "userSERIALout"  Function 

This  function  is  used  to  accommodate  output  data  and  is  not  used  in  our 

case. 


3.  The  "user  sample_SERL4L  in"  Function 

This  function  is  composed  of  two  parts.  One  that  reads  channelA,  and 
one  that  reads  channelB.  It  is  called  two  times  per  sampling  interval,  one  for 
channelA  and  one  for  channelB.  The  channel  called  specifies  one  of  the  three 
calling  parameters  of  the  function,  the  unsigned  integer  ser_channel . 

The  second  calling  parameter  is  the  float  array,  model_f  loat  [  ] 
which  is  the  vector  to  be  filled  with  values  that  will  transfer  to  the  executed 
model  as  inputs.  This  second  parameter  has  length  equal  to  the  number  of 
parameters  of  the  model  that  are  expected  as  inputs  from  the  serial  IP  module. 
Note  that  the  two  physical  channels  A  and  B,  are  assigning  values  to  the  same 
elements  of  the  model_f  loat  f  ] ,  i.e.  one  to  twenty  six.  This  is  perfectly 
all  right,  as  the  two  physical  channels  are  never  active  on  the  same  call  of 
"usersampleSERIALin" . 

The  GPS  receiver  that  will  be  placed  on  Archytas  is  connected  to 
channelA  and  outputs  three  messages.  The  first  begins  with  the  string 
"@@Ba"  and  contains  the  Latitude,  Longitude,  Height,  Velocity  and  Heading 
of  the  receiver.  At  first  the  routine  detects  the  string  "@@Ba"  and  then  the 
function  read_serial  reads  from  the  input  buffer  the  expected  number  of 
bytes  in  the  message  (section  4.7  of  Ref.2).  The  message  is  then  parsed,  and 
the  bytes  that  contain  a  specific  variable  are  multiplied  by  their  hexadecimal 
value  and  summed  together.  Then  the  variables  that  need  scaling  are  scaled 
accordingly  in  order  to  obtain  the  specified  resolution. 

Next  step  is  to  create  the  checksum  (the  exclusive-or  of  all  the  bytes 
received  after  the  heading  string  "@@Ba”)  and  to  compare  it  with  the  one 
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received  from  the  message.  If  both  checksums  agree  the  obtained  values  are 
placed  in  the  appropriate  elements  of  the  model_float  []  array.  If  the 
checksums  don't  agree,  then  the  last  correct  value  of  the  variables  is  returned, 
being  stored  in  the  global  variable  last_f  loat  []  . 

The  same  procedure  is  used  to  decode  the  messages  that  contain  the 
ECEF  coordinates  of  the  receiver  plus  its  velocity  components  in  the  tangent 
plane  coordinate  system,  ("@@Bk  ...  "),  and  the  message  that  contains  the 
pseudorange  and  pseudorange  rate  information,  ("@@Bg  ...  "). 

The  receiver  used  as  the  DGPS  reference  station  is  hooked  to  channelB. 
It  produces  only  the  pseudorange  and  pseudorange  rates  correction  message, 
("@@Ce  ...  ").  This  message  is  decoded  using  the  usual  procedure.  It  has  to 
be  noted  that  the  portion  of  the  code  that  reads  channelB  together  with  the 
portion  of  the  code  of  channelA  that  outputs  the  pseudoranges  and 
pseudorange  rates,  (message  "@@Bg  ...  "),  have  a  rather  indirect  value  as 
their  outputs  will  not  be  used  by  the  Archytas  flight  controller  at  the  present. 
The  reason  that  have  been  developed  is  to  facilitate  a  future  approach  of  the 
positioning  problem  as  described  in  Chapter  III,  section  B. 

Especially  the  outputs  of  the  "@@Ce  ..."  message  won't  even  show  up 
on  the  screen  of  the  UNIX  monitoring  station,  as  the  signal  will  be  fed  directly 
to  the  Archytas  GPS  receiver  during  the  DGPS  setup.  At  this  case  the  fourth 
icon  will  show  the  arbitrary  default  values  of  seven,  denoting  absence  of  data. 
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VI.  SETTING  UP  THE  DGPS 


The  differential  GPS  setup  is  discussed  at  this  chapter.  This  will  be 
suitable  for  equipment  testing  and  performance  evaluation.  With  a  suitable 
radio  link,  this  setup  can  be  expanded  to  one  installed  on  a  flying  vehicle. 


A.  GPS  RECEIVERS  INITIALIZATION  AND  CONFIGURATION 

The  Motorola  binary  communication  format  gives  the  user  the  capability 
to  fully  define  the  receiver's  operating  parameters  and  mode  of  operation 
during  initialization,  as  well  as  during  the  receiver's  normal  operation.  Note, 
our  application  has  one  special  characteristic.  Since  the  UAV  will  be  flying 
away  from  the  controlling  station,  the  GPS  receivers  should  be  properly 
preconfigured,  as  real  time  control  of  them  will  not  be  possible  with  the 
existing  setup  of  the  Archytas  controller. 

A  full  duplex  radio  link  will  connect  the  UAV  receiver  with  the  base 
station.  The  differential  station  will  send  corrections  to  the  UAV,  while  the 
UAV  will  report  its  position  to  the  flight  control  computer  that  stays  on  the 
ground.  Any  desired  commands  to  the  UAV  GPS  receiver  will  have  to  be 
transmitted  through  the  differential  corrections  wireless  circuit,  and  into  the 
PVT-6's  single  I/O  port.  To  make  sure  that  the  commands  and  the  corrections 
won't  interfere  with  each  other  on  the  sole  frequency  provided,  some  form  of 
system  controller  has  to  be  installed  to  handle  both  inputs.  For  details  see 
paragraph  4.4.2  of  Ref.2.  Fig. 6.1  shows  a  similar  setup,  where  a  control  unit 
makes  sure  that  both  differential  corrections  from  a  Coast  Guard  Station,  and 
GPS  commands,  enter  a  PVT-6  receiver  without  any  data  collision. 

Similar  setup  is  also  achievable  using  our  AC  100  model  C30  based 
controller,  however  the  software  needed  to  realize  it  is  not  available  at  this 
time.  Apart  from  that,  a  carefully  planned  GPS  receiver 
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initialization-configuration  should  be  sufficient  for  our  application,  so  that  the 
real  time  control  of  the  unit  is  not  required  and  the  added  complexity  is 
avoided.  A  setup  without  real  time  control  of  the  receiver  is  shown  in  Fig.6.2. 

1.  Configuring  The  UAV  Receiver 

An  easy  way  to  configure  the  PVT-6  is  to  use  the  evaluation  software 
kit  which  runs  on  a  PC  and  is  provided  by  Motorola.  The  only  thing  the  user 
is  required  to  have  is  a  cable  connection  that  will  merge  the  power  supply 
wires  and  a  nine  or  twenty  five  pin  standard  serial  connector,  into  a  socket 
that  will  be  connected  to  the  receiver's  I/O  ten  pin  port.  The  standard  serial 
connector  would  be  hooked  to  any  of  the  PC's  available  serial  ports  (usually 
serial  port  number  two),  and  the  GPS  program  should  be  run.  Detailed 
instructions  for  the  whole  setup  are  provided  by  Ref.  7.  The  setup  diagram  is 
shown  in  Fig. 6. 3. 

Although  this  is  not  the  proper  way  to  configure  the  PVT-6,  it  works 
fine  and  is  also  very  useful  in  revealing  the  receiver's  little  "secrets",  that  one 
can  uncover  after  playing  around  with  the  program  for  a  while.  First  we  are 
going  to  examine  the  UAV  receiver  configuration. 

The  receiver  is  forced  into  the  Motorola  Proprietary  Binary  format 
each  time  the  GPS  program  is  started.  Following  the  instructions  of  Ref. 7, 
page  9,  we  initialize  the  receiver.  Then  we  use  the  following  commands  in 
order  to  configure  it: 

♦  mode :  f,  forcing  the  receiver  to  the  fix  mode,  instead  of  idle. 

♦  ah  :  d,  disabling  the  altitude  hold  feature. 

♦  almhold  :  u,  the  receiver  updates  its  internal  almanac  when  it  receives  a  new 
one. 

♦  aptype  :air,  optimizing  the  receiver  for  airborne  use. 
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datum  :  49,  to  make  sure  that  the  receiver  calculates  its  coordinates  on  the 
WGS-84  datum. 

doptype  :  PDOP,  to  tell  the  receiver  to  use  the  Position  Dilution  of  Precision 
type  for  its  satellite  selection  criteria  (instead  of  geometrical,  horizontal,  vertical 
or  time  dilution  of  precision).  The  DOP  is  a  figure  that  characterizes  a  given 
combination  of  GPS  satellites.  Depending  on  the  relative  satellite  position,  a 
given  combination  increases  the  uncertainty  of  position  or  time  estimation  of  the 
receiver,  by  a  smaller  or  a  bigger  amount.  The  DOP  figure  is  a  multiplier  to  the 
already  existing  uncertainty  value,  thus  yielding  the  total  uncertainty  after 
introducing  the  relative  satellites  position  factor.  The  receiver  can  calculate 
internally  the  various  DOP  figures  so  as  to  track  the  most  favorable  satellite 
combination.  In  our  case  we  have  selected  the  Position  DOP  as  this  criterion. 

dophys  :  10.0,  sets  the  PDOP  threshold  above  which  the  receiver  will  switch 
from  2D  positioning  to  no  positioning. 

dopmask :  10.0,  sets  the  PDOP  threshold  above  which  the  receiver  will  select  a 
new  set  of  satellites. 

dopthr :  10.0,  sets  the  PDOP  threshold  above  which  the  receiver  will  switch 
from  3D  positioning  to  2D  positioning.  The  value  that  we  selected  for  the 
above  PDOP  parameters  is  arbitrary.  The  value  of  ten  is  a  relatively  high  value 
yielding  inaccurate  results.  This  value  was  selected  though  so  that  the  receiver 
is  given  enough  uncertainty  tolerance  that  it  doesn't  change  satellite 
combinations  continuously,  in  order  to  achieve  a  small  value  of  PDOP.  Each 
time  the  satellite  combination  changes,  an  undesirable  discontinuity  in  the 
receiver's  fix  coordinates  is  observed. 

ephhold  :  0,  tells  the  receiver  to  acquire  the  latest  ephemeris  data,  whenever 
available. 

epoch  :  0.0,  tells  the  receiver  that  no  time  shift  of  its  calculated  outputs  is 
needed. 

fix  :  n,  specifies  that  the  receiver  will  track  six  satellites  if  available,  in  order  to 
calculate  its  outputs.  The  other  option  is  to  track  the  best  four  satellites 
combination,  i.e.  the  minimum  number  required  for  a  position  fix.  Our  choice  is 
based  on  the  fact  that  the  loss  of  tracking  of  one  satellite,  "upsets"  the  solution 
less  in  the  first  case. 

ion  :  e,  enables  the  ionospheric  correction  model. 

mask :  10,  make  sure  that  the  minimum  elevation  angle  at  which  the  receiver 
will  attempt  to  track  satellites  is  at  the  default  value  of  10.0. 

ph:d,  to  make  sure  that  the  receiver  does  not  operate  in  differential  mode. 
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♦  pos  :  1,  with  this  command  we  actually  tell  the  receiver  to  output  the  Position 
/Status  /Data  message  ("@@Ba  ..."),  once  per  second.  The  GPS  program 
software  internally  creates  the  required  "@@BamC<CR><LF>"  message  that  is 
described  in  page  4-80  of  Ref.  2,  and  sends  it  to  the  receiver. 

•  rng  :  1,  the  same  procedure  as  above  followed,  the  receiver  now  also  outputs 
the  "@@Bg  ..."  message  once  per  second. 

It  turns  out,  however,  that  not  all  the  receiver's  messages  can  be 
requested  with  the  evaluation  software  kit.  This  is  the  case  for  the  third 
message  that  we  need:  the  Position  /Status  /Data  extension  message 
("@@Bk...").  In  order  to  have  it  included  in  the  receiver  output  we  have  to 
develop  our  own  executable  program  that  will  send  the  receiver  the  command 
character  string  "@@BkmC<CR><LF>".  This  string  is  sent  via  the  AC  100 
model  C30  computer,  by  using  the  AC  100  environment,  and,  in  particular,  the 
"user_ser.c"  user  interface  to  the  IP- Serial  Device  Driver.  This  is  done  with 
the  ”user_SERIAL_out"  function  in  a  way  similar  to  that  of  the 
"usersampleSERIALin"  function.  Detailed  description  on  how  to  use  this 
function  are  given  in  pages  136-139  in  Ref.  5. 

This  user  ser.c  file,  (Appendix  D),  is  completely  unrelated  to  the  main 
project  named  "gps".  It  is  executed  by  itself,  and  resides  in  a  project  folder 
named  "bk",  with  the  sole  purpose  of  sending  the  GPS  receiver  the  above 
mentioned  command  character  string.  What  we  have  to  do  next  is  to  unhook 
the  receiver's  serial  cable  from  the  PC,  and  to  hook  it  to  the  IP-Serial  module, 
channelA  of  the  C30.  Next  step  is  to  run  the  "bk"  project  for  a  few  seconds  to 
make  sure  that  the  receiver  gets  the  command  string. 

By  now  We  have  initialized  the  GPS  receiver,  defined  critical  operating 
parameters,  and  forced  it  to  output  the  three  messages  that  we  are  interested 
in,  at  the  rate  of  one  Hz.  The  receiver  will  keep  this  configuration  in  its  non 
volatile  internal  memory,  so  that  it  will  behave  the  same  each  time  it's  powered 
up.  A  very  simple  way  to  check  if  it  outputs  the  correct  messages  is  to  hook 
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to  a  serial  port  of  a  PC.  By  entering  Windows  and  running  the  Terminal 
program  we  should  clearly  see  on  the  screen  the  headers  "@@Ba",  "@@Bk", 
and  "@@Bg"  followed  by  meaningless  symbols.  These  latter  symbols  appear 
because  Terminal  fails  to  translate  the  complicated  Motorola  Binary  Format 
byte  stream  into  ASCII  characters. 

2.  Configuring  The  Reference  Receiver 

The  reference  receiver's  initialization  procedure  is  exactly  the  same  as 
for  the  UAV  receiver  with  the  following  differences: 

•  instead  of  requesting  the  three  mentioned  output  messages  of  the  UAV 
receiver,  we  request  the  output  of  differential  corrections  by  using  the 
corout :  1  command  from  the  evaluation  software  kit. 

•  We  also  tell  the  receiver  to  hold  its  position  in  order  to  extract  differential 
corrections  using  the  ph  :  e  command  from  the  same  environment. 

•  We  specify  the  position  hold  coordinates  of  the  reference  receiver,  i.e.  the 
receiver's  position,  by  using  the  command  php  (lat  Ion  hgt  [gps|msl]),  as 
specified  in  page  36,  Ref.7. 

The  reference  receiver  will  also  keep  these  settings  after  powered  off, 
as  they  are  registered  in  its  internal  non  volatile  memory. 

B.  HARDWARE  CONNECTIONS 

As  soon  as  the  two  receivers  are  initialized  and  configured,  they  are 
ready  for  the  differential  setup.  The  UAV  receiver's  serial  I/O  port  is  hooked 
to  the  IP-Serial  module  number  3,  channelA,  of  the  AC  100  model  C30, 
through  a  special  adapter  cable.  The  GPS  receiver's  serial  port  is  interfaced 
using  a  standard  nine  pin  serial  connector.  Pins  8,9  and  10  of  Fig. 4. 3  are 
accessed  via  the  pins  2,  3,  and  5  of  the  serial  connector,  representing  the 
RS-232  transmit,  (TXD),  receive,  (RXD),  and  ground,  (RTN),  signal  levels. 
The  equivalent  pins  of  the  50  pin  IP-Serial  connector  are  shown  in  Fig. 4. 8. 
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The  reference  GPS  receiver  can  be  either  connected  to  the  C30,  for 
outputs  to  be  monitored  and  recorded,  or  it  can  be  connected  directly  to  the 
UAV  receiver  by  means  of  wires,  providing  the  latter  with  differential 
capability.  In  the  first  case  the  connections  follow  the  same  rules  as  in  the 
paragraph  above.  The  only  difference  is  that  instead  of  channelA,  it  should  be 
connected  to  channelB.  In  the  second  case,  pin  2  of  the  reference  receiver's 
nine  pin  serial  connector  is  connected  to  pin  3  of  the  UAV  receiver's  nine  pin 
serial  connector.  We  also  make  sure  that  pins  5  of  both  receivers  are 
connected  together,  so  that  the  two  devices  share  the  same  ground. 

During  the  actual  implementation  of  the  DGPS  setup,  all  wired 
connections  leading  to  the  UAV  receiver  will  be  substituted  by  a  radio  link. 
The  only  requirements  for  the  radio  link  are  to  operate  at  9600  baud  and  to  be 
transparent  to  the  user. 
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VII.  ON  THE  FIELD  TESTING  AND 
PERFORMANCE  EVALUATION 


The  task  that  concludes  this  thesis  is  the  actual  positioning  data 
collection  and  evaluation.  The  PVT-6  receiver  was  operated  on  DGPS  and 
non  DGPS  mode,  and  the  data  was  compared  together.  Finally,  some  thoughts 
on  the  DGPS  aided  navigation  system  setup  are  presented. 


A.  EQUIPMENT  SETUP 

As  a  full  duplex  data  link  was  not  available  during  this  thesis  work,  both 
receivers  were  placed  next  to  each  other  with  the  differential  receiver 
providing  pseudorange  corrections  via  cable  link.  The  antennas  were  also 
placed  side  by  side.  The  location  where  the  experiment  was  held  did  not  have 
an  unobstructed  view  of  the  GPS  satellites,  as  trees  blocked  about  one  fourth 
of  the  sky.  For  this  reason  the  differential  capability  was  lost  many  times, 
yielding  a  degraded  position  accuracy. 

Whether  the  UAV  receiver  was  operating  in  differential  mode,  or  not, 
could  be  verified  by  monitoring  the  value  of  the  receiver  status  byte,  which  is 
part  of  the  Position\Status  message  ("@@Ba  ...  ").  The  status  byte  at  any 
instant  indicates  the  receiver's  mode  of  operation,  for  example  Differential, 
3DFix,  Altitude  Hold,  etc.,  depending  on  the  value  of  the  byte.  We  first 
examined  the  non-differential  positioning  data. 


B.  NON  DIFFERENTIAL  POSITIONING  DATA 

Non  differential  positioning  data  was  collected  several  times.  A  typical 
set  of  data  covering  a  time  period  of  about  half  an  hour  is  presented  next. 
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The  data  was  gathered  on  Wednesday,  May  24,  at  the  Naval 
Postgraduate  School  golf  course  at  a  location  of  Latitude  36°35/22/7V 
(1317220  deciseconds)  and  Longitude  121°  5 \'  49"  W  (-4387090  deciseconds). 

Fig. 7.1  shows  the  variation  in  Latitude.  During  the  1250  seconds  of 
data  collection,  the  amplitude  of  the  latitude  change  was  about  70  meters 
(shown  here  in  deciseconds  of  a  degree  of  latitude).  Fig. 7.2  shows  the 
equivalent  graph  for  the  longitude.  Again  the  amplitude  was  about  70  meters. 
Fig.  7. 3  shows  the  plot  of  latitude  versus  longitude.  The  height  plot  is  shown 
in  Fig. 7.4.  Here  the  amplitude  was  440  meters.  It  is  obvious  that  the  non 
differential  position  information  cannot  be  used  by  a  flight  controller  due  to  its 
inaccuracy  and  great  variations. 

C.  DIFFERENTIAL  POSITIONING  DATA 

A  big  improvement  in  position  accuracy  was  observed  in  the  differential 
setup.  Fig. 7. 5  shows  the  latitude  values  obtained  during  1800  seconds  of  data 
collection.  First,  note  that  the  receiver  is  operating  in  differential  mode  from 
0  to  250  seconds,  and  then  again  from  1000  to  1800  seconds.  This  can  be 
clearly  seen  by  examining  the  receiver  status  byte  (Fig. 7. 15). 

The  differential  three  dimensional  position  fix  mode  was  not  available 
from  the  PVT-6  receiver  all  the  time.  This  is  because  the  differential  station 
would  either  not  output  corrections  for  all  the  satellites  used  by  the  second 
receiver,  (status  byte  =  32  case,  non  differential  three  dimensional  mode),  or 
both  receivers  would  track  three  satellites  only,  (status  byte  =  20  case, 
differential  two  dimensional  mode).  The  loss  of  tracking  in  each  case 
happened  because  the  location  of  the  experiment  did  not  have  unobstructed 
view  of  the  sky  resulting  in  satellite  "loss"  when  the  latter  moved  behind  the 
trees  present.  This  factor  can  be  eliminated  by  choosing  another  location  for 
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the  differential  station.  The  receiver  onboard  Archytas  should  have  no 
problem  as  the  vehicle  will  have  good  visibility  while  flying. 

The  variations  in  latitude  is  now  plus  or  minus  3  meters.  The  plot  for 
longitude  reveals  also  plus  or  minus  3  meters  variations  (Fig. 7.6).  The  plot  of 
latitude  versus  longitude  is  shown  in  Fig. 7. 7.  Here  the  axis  have  the  same 
scaling,  i.e.,  each  tic  mark  represents  one  decisecond,  or  three  meters.  The 
dense  part  of  the  graph  around  the  point  (-4387088,  1317218)  represents  the 
data  corresponding  to  the  differential  operation  mode.  The  height  data  also 
shows  great  improvement,  with  variations  of  only  plus  or  minus  5  meters 
(Fig. 7. 8). 

The  most  interesting  results  are  shown  in  Figs. 7.9,  7.10  and  7.11.  Here 
the  x,  y,  and  z  ECEF  coordinates  are  shown  in  meters.  During  the  differential 
operation  of  the  receiver  the  variation  is  plus  or  minus  25  centimeters  for  x 
and  y  coordinates,  and  plus  or  minus  1  meter  for  the  z  coordinate.  This 
sub-meter  accuracy  deserves  some  attention.  The  question  is  why  the  position 
expressed  in  geodetic  coordinate  system  has  a  plus  or  minus  3m  variation, 
while  when  expressed  in  ECEF  coordinates  a  25cm  variation  is  observed.  This 
question  could  not  be  answered  within  this  thesis  timeframe,  however  one 
answer  is  obvious. 

The  coordinate  system  in  which  GPS  internally  expresses  all  positions 
(satellite's  and  receiver's)  is  the  ECEF.  In  order  to  transform  the  ECEF 
coordinates  into  Geodetic  ones,  a  non  linear  analytically  unsolvable  equation 
has  to  be  solved.  The  position  errors  are  amplified  during  the  iteration 
process  used  to  solve  the  latter  equation.  This  one  reason  for  the  Geodetic 
position's  decreased  accuracy. 

The  velocity  components  in  the  Tangent  Plane  coordinate  system  are 
shown  in  Fig. 7. 12,  Fig7.13,  and  Fig7.14.  The  amplitude  here  is  plus  or  minus 
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0.1  meters  per  second  around  the  0.0  m/s  true  value  (receiver  is  stationary) 
during  the  differential  portion. 

The  last  figure  (Fig. 7. 15)  shows  the  value  of  the  receiver  status  byte 
during  the  1800  second  interval.  The  status  byte  has  the  value  of  36  from  0 
seconds  to  330  seconds  and  from  1000  to  1800  seconds.  According  to  Ref.2 
that  means  that  the  receiver  was  operating  in  differential  three  dimensional 
position  fix  mode.  In  between,  the  status  byte  had  the  values  of  32  or  20 
which  means  that  the  receiver  was  operating  in  non  differential  three 
dimensional  mode  or  differential  two  dimensional  mode  respectively,  which 
explains  the  inaccurate  results  during  this  time  interval. 

Operating  in  differential  three  dimensional  position  fix  mode,  the 
PVT-6  gives  results  accurate  enough  to  be  used  by  the  Archytas  flight 
controller.  The  information  to  be  provided  to  the  controller  is  the  ECEF 
position,  which  can  be  easily  transformed  into  a  Tangent  Plane  position,  and 
the  Tangent  Plane  velocity  components.  The  reason  for  this  preference  is  that 
the  above  information  is  ready  to  be  blended  with  the  inertial  measurement 
unit  outputs,  as  the  latter  are  expressed  in  the  Tangent  Plane  system  as  well. 

If  Archytas  is  meant  to  be  flown  far  away  from  the  differential 
station  we  should  consider  using  a  twelve  channel  parallel  receiver  at  the  base, 
just  to  make  sure  that  differential  corrections  are  available  for  whatever 
satellites  the  Archytas  receiver  is  tracking. 
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VIII.  CONCLUSION 


This  thesis  task  is  to  provide  three  dimension  position  and  velocity 
information  to  the  Archytas  flight  control  computer,  using  Differential  Global 
Positioning  technique. 

The  GPS  receivers  used  are  two  Motorola  PVT-6  OEM's.  The 
Motorola  Binary  Proprietary  format  was  chosen  as  the  communication 
protocol  between  the  flight  control  computer,  which  is  the  AC  100  model  C30 
by  ISI,  and  the  PVT-6,  as  well  as  between  the  receivers  themselves.  The  main 
tasks  of  this  thesis  were  the  following  three. 

♦  To  decode  the  GPS  message  (Motorola  proprietary  format)  in  order  to  have 
usable  numerical  results. 

♦  To  create  the  suitable  environment  into  the  AC  100  modelC30  that  will  accept 
and  process  the  GPS  positioning  information. 

♦  To  set  up  the  actual  DGPS  system,  collect  data  and  verify  that  they  are  accurate 
enough  to  be  used  by  the  Archytas  flight  controller. 

To  reach  the  first  objective,  two  C-code  files  were  written.  These  files 
are  shown  in  appendices  B  and  C. 

A  model  that  reads  seventy  seven  variables  was  built  to  reach  the 
second  objective.  The  variable's  values  are  obtained  from  the  GPS  receivers 
through  the  Serial  input-output  IP  module.  After  the  data  is  decoded 
according  to  the  previous  paragraph,  it  can  be  recorded,  analyzed,  or  directly 
fed  into  the  flight  controller. 

Finally,  the  setup  of  the  DGPS  system  was  completed.  The  data 
collected  showed  an  accuracy  of  plus  or  minus  3m  (geodetic  coordinates),  to 
plus  or  minus  25cm  (ECEF  coordinates). 
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This  level  of  accuracy  permits  the  flight  controller  to  blend  the  GPS  and 
the  Inertial  Measurement  Unit  positioning  data,  so  as  to  enhance  its  navigation 
problem  solution. 
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APPENDIX  A.  :  FIGURES 


SPACE 

SEGMENT 


NAVIGATIONAL  (L1/L2) 
SIGNALS: 

•  RANGING  CODES 

•  SYSTEM  TIME 

•  CLOCK  CORRECTION 

•  PROPAGATION  DELAY 

•  VEHICLE  EPHEMERIS 

•  VEHICLE  HEALTH 


USER 
SEGMENT 


PLANNED  CONSTELLATION: 

•  21  ACTIVE  SATELLITES  PLUS  3  SPARES  IN  6  ORBITS 

•  EACH  ORBIT  AT  55  0EGREE5  INCLINATION 

•  ORBITS  EQUALLY  SPACED  AROUND  EQUATOR 


DOWNLINK  DATA: 

•  SATELLITE  EPHEMERIS  (ORBITAL  POSITION)  DATA 

•  SATELLITE  CLOCK  DATA 


UPLINK  DATA: 

•  SATELLITE  EPHEMERIS  CORRECTIONS 

•  CLOCK  CORRECTIONS 


CONTROL 

SEGMENT 


CONTROL  SEGMENT  SITE  LOCATIONS: 

MASTER  CONTROL  STATION  -  COLORADO  SPRINGS 

MONITOR  STATIONS  -  COLORADO  SPRINGS 
ASCENSION 
DIEGO  GARCIA 
KWAJALEIN 
HAWAII 


UPLINK  STATIONS  -  ASCENSION 

DIEGO  GARCIA 
KWAJALEIN 


Fig.2.1  The  GPS  segments.  From  Ref.2 
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GPS  Satellites 


Name:  NAVSTAR 

Manufacturer:  Rockwell  International 
Altitude:  10,900  nautical  miles 
Weight:  1900  lbs  (in  orbit) 

Size:  17  ft  with  solar  panels  extended 
Orbital  Period:  12  hours 
Orbital  Plane:  55°  to  equatorial  plane 
Planned  Lifespan:  7.5  years 
Number  built:  1 1  Block  I  prototype 
satellites  28  Block  II  production 
satellites 

Constellation:  24  satellites 


Fig.2.2  The  GPS  satellite.  From  Ref  8 


Fig.4. 1  The  PVT-6  receiver.  Internal  view.  From  Ref.2 
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Pin  Number 

Signal  Name 

Description 

1 

+  12V/+5V  BATT 

(Optional)  +5  Vdc  regulated  or  +12  Vdc  unregulated  for  running 

Real  Time  Clock  and  retention  of  satellite  ephemeris  information 
stored  in  keep-alive  RAM  memory 

2 

+5V  MAIN 

(Optional)  +5  Vdc  regulated  for  power  requirements  of  entire 

GPS  Receiver  (+12  Vdc  signal  net  used) 

3 

+  12V/+5V  RTN 

Power  supply  (+5V  or  +12V)  return 

4 

Vpp2 

Flash  memory  (EPROM)  programming  voltage 

5 

+  1 2V  MAIN 

+  12  Vdc  unregulated  for  power  requirements  of  entire  GPS 

Receiver 

6 

1  PPS3 

(Option  A)  1  pulse  per  second  output 

7 

1  PPS  RTN 

(Option  A)  1  pulse  per  second  return 

8 

RS232  TXD 

Serial  RS232  data  output 

9 

RS232  RXD 

Serial  RS232  data  input 

10 

RS232  RTN 

Signal  return  for  RS232  signals 

'AMP  connector  PN  104369-4  (installed  PCB);  PN  103681-2  (mating) 
2Not  used  (used  only  by  Motorola  for  updating  of  software) 

31  Hz  pulse  train  with  rising  edge  coincident  with  UTC/GPS  1  second  tick 


ANTENNA  DATA/PQWER 

CONNECTOR  CONNECTOR 


Fig.4.3  The  PVT-6  receiver's  serial  port.  From  Ref.2 
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Fig.4.5  The  PVT-6  receiver.  From  Ref.2 
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>■ 


EVENT 

Connector 


DSPLINK 

Connector 


Fig.4.6  The  DSPFLEX  board.  From  Ref.2 


DSPFLEXBd 

1 

DSPFLEX  Bd  2 

DSPFLEX  Bd  3 

DSPFLEXBd  4 

Position 
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Position 
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D 

8 

D 
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16 

Fig.4.7  The  IP  modules.  From  Ref.2 
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Fig.4.9  AC100  model  C30  hardware  setup.  From  Ref.5 


53 


Interactive^ 


nteractive^An 


Fig. 5. 4  Pseudoranges  GUI  screen 
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M  |.<t  s| 


SATELLITE  SIGNALS 
i  $75  GH: 

50  BPS  I8PSKI 


/ 


♦  12  VOC  TO  USER  EQUIPMENT  +5  VDCOR 

+12VOC 


Fig.  6. 1  DGPS  setup  not  requiring  real  time  control.  From  Ref.2 


DIFFERENTIAL 
CORRECTIONS 
300  kHz 
50  BPS  (MSK) 
RTCM  SC- 104  FORMAT 


Fig. 6.2  DGPS  setup  requiring  real  time  control.  From  Ref.2 


60 


Motorola  GTS  Antenna 


RG-5S  Coaxial  Cable 


OSX 

Connector 


I  Motorola 
I  GPS  Receiver 


lortn 

Rectangular 

Connector 


Power/Data  Cable 


PC  Controller 
Display 


IBM  PC  or  Compatible 
A 
f 


RS-23J 
V  pin) 

D  connector 


FC  Controller 
Software 


One  rrs 

(yellow) 

One  TPS  Return 
(orange) 

5/I2VRTN 

(white) 

12V  SW  _ 
(gray) 

5/I2V  Datt 
(brown) 

5  V  Main 
(blue) 

vrp 

(purple) 


Fig.6.3  Configuration  of  the  PVT-6  via  the  PC.  From  Ref.7 
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Fig.7.6  Longitude,  differential  setup. 
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Fig.  7. 10  ECEf  y  coordinate,  differential  setup. 
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Fig.7.12  Tangent  Plane  coordinates.  North  velocity  component,  differential  setup. 
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Fig.7.13  Tangent  Plane  coordinates.  East  velocity  component,  differential  setup 


Fig.7.14  Tangent  Plane  coordinates.  Up  velocity  component,  differential  setup. 
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APPENDIX  B. :  TABLES 


Table  4.1  PVT-6  specifications  From  Ref.2 


Parameter 

Description 

Dynamics 

•  Velocity  1000  Knols  (514.4  m/sec) 

•  Acceleration  4  g 

•  Jerk  5m/s3 

Antenna 

•  Active  microstrip  patch  Antenna  Modute 

•  Powered  by  Receiver  Module  (5  Vdc  25  mA) 

Antenna  to  Receiver 

Interconnection 

•  Single  coaxial  cable  (6dB  max  loss  at  LI:  1575.42  MHz) 

•  Typical  length  with  RG58  coaxial  cable:  20  leet  (8  melers) 

Serial  Output 

•  RS232C  Interface 

Accuracy 

•  Less  than  25  melers.  SEP  (without  SA) 

•  DoD  may  Invoke  Selective  Availability  (SA),  potentially  degrading 
accuracy  to  100  meters  (2d  RMS) 

Altitude 

•  60.000  feet  (18  Km)  (maximum) 

Operating  Temperature 

•  Active  Antenna  -40X  to +100X  |-4(PF  to +212-F) 

•  Receiver  Module  -30CC  to  +80CC  (-22rF  to  1 76’F) 

Humidity 

•  95%  non-condensing  +3<TC  to  +60C  (+867F  to  +  14ITF) 

Physical  Dimensions 

•  Receiver  PC0  3.94  X  2.76  X  0.65  In  (100  X  70  X  16.5  mm) 

•  Antenna  Module  4.01  (dla)  X  0.89  In  (102  (dla)  X  22.6  mm) 

Weight 

•  Receiver  and  Housing  4.5  02  (128  g) 

•  Antenna  Module  4.8  oz  (136.2  g) 

Switched  Power 

•  9  to  16  Vdc  or 

•  5  ±  0  25  Vdc 

"Keep-Alive"  BAIT  Power 

•  4.75-  16  Vdc:  0.3mA  ...  f/ 

Power  Consumption  (typical) 

•  1.3  W  ft  5  Vdc  input 

•  t.BWft  12  vdc  input 

Receiver  Interconnection 

•  AMP  to  pin.  »t 04369-4  on  Receiver  Module 

-  RS232C 

-  Power  input 

•  OSX  connector  on  Receiver  and  Antenna 

MTBF  (Mean  Time  Before  Failure) 

•  55.000  hours  (estimated) 
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Table  5.1  PVT-6  basic  output  messages.  From  Ref. 2 


OUTPUT  MESSAGE  TYPE 

CONTINUOUS  (m=1...255) 

ONE  TIME  (m=0) 

Position/Channel  Status 

At  selected  update  rate 

When  requested 

Satellite  Range  Data  Output* 

At  selected  update  rate 

When  requested 

Pseudorange  Correction  Output* 

At  selected  update  rate 

When  requested 

Ephemeris  Data  Output 

When  Eph  data  changes 

When  requested 

Visible  Satellite  Status 

When  Vis  data  changes 

When  requested 

DOP  Table  Status 

When  DOP  data  changes 

When  requested 

Almanac  Status 

When  Aim  status  changes 

When  requested 

Almanac  Data  Output 

When  Aim  data  changes 

When  requested 

Leap  Second  Pending 

When  Requested 

'These  output  messages  are  available  only  as  an  option. 
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Table  5.2  PVT-6  differential  capability.  From  Ref.2 


FORMAT 

TYPE  r 

BAUD 

BITS 

START/ 

STOP 

PARITY 

FEATURES 

DIFFERENTIAL 

CAPABILfTY 

Motorola 

Binary 

9600 

8 

1/t 

No 

Full  Control/All 

Data 

RTCM  SC- 104’ 
and  Custom2 

NMEA-0103 

ASCII 

4800 

8 

1/1 

No 

Partial  Control/ 

Selected  Mes¬ 
sages 

RTCM  SC- 104' 

LORAN 

1 

Emulation 

ASCII 

1200 

8 

1/1 

No 

Little  Control/ 

1  Output  Message 

None 

Notes:  1.  RTCM  SC-104  decoding  of  Message  Type  #1  exists  in  de-optloned  units. 
It  is  available  to  all  users  at  no  additional  cost. 

2.  The  custom  differential  capability  is  available  as  Option-B  only. 
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APPENDIX  C. :  USERJSER.C-GPS  PROJECT 


j  *  ★  ★ 


USER_SER . C  PROJECT  GPS 


★  *  *  j 


/************************************************************ 
**@  File  :  user_ser.c 

**@  Project  :  Acl00/c30 
**@  Edit  level  :  3 


**@  Abstract: 

**@ 

**@ 

**@ 

* 

**@ 

* 


File  contains  functions  which  the  user 

must  define  to  interface  with  IP-SERIAL  device 

driver . 

The  functions  must  be  called 

get_SERlAL_parameters 
user_po 1 1_SERI AL_ou t 
user_sample_SERIAL_in 

Templates  for  the  functions  are  provided. 
get_SERIAL_parameters 

Function  sets  the  asynchronous  communication 
parameters  for  the  IP-SERIAL  module.  Ring  buffer 
sizes  used  to  store  received  data  must  also  be 
specified. 

user_poll_SERIAL_out 

Function  is  called  with  the  floating-point 
model  output  vector  for  the  current  sampling  interval. 
The  user  is  responsible  for  creating  the  transmit 
byte  array  and  calling  function  write_serial  which 
transmits  the  byte  array  across  the  serial  channel. 


**@  user_sample_SERIAL_in 

**@  Function  is  called  every  sampling  interval.  The 

**@  user  is  responsible  for  filling  the  floating-point 

**@  vector  which  is  used  as  input  to  the  model  for 

**@  the  current  sampling  interval. 

*  *@ 


**@  Modifications: 

**@ - 

**@  Creation  : 

**@  Revised  : 

**@  Revised  : 

**@  Revised  : 

**@  Revised  : 

*/ 


7- 1 — 93  Henry  Tominaga 

8- 23-93  Brent  Roman 
11-18-93  Steve  Lynch 
2-27-95  Christof is/Hallberg 
4-27-95  Christofis 


#include  <stddef.h> 
iinclude  <stdlib.h> 

# inc lude  “ s a_type s . h " 
# include  “types.h" 
#include  "ioerrs.h" 

# inc lude  "err codes .h" 


#include  " iodriver .h" 

#include  "ipserial.h" 

#include  “printx.h" 

# include  <math.h> 

#def ine  NULL  0 

/*  semaphores  and  serial  parameters  for  each  physical  channel  */ 
private  struct 

{  boolean  allSent;  boolean  broken;  unsigned  baud;}  line_state [2] ; 

struct  user_type 

{ 

int  update_interval ; 
int  update_count ; 


} ; 


boolean  first_frame  =  true; 

float  last_float [77] ,  sol=299792458 . 0,  Ilf 0=1575420000 . 0 ,  k2; 

unsigned  long  icpoldl,  icpold2,  icpold3,  icpold4,  icpold5,  icpold6; 

/*********************************************************** 

*★**•******■*★*****■**★★**★★****★*★*★**★*■*■*********★★★★**★•***★ 

@@  THE  INTERNALS  OF  THE  FOLLOWING  THREE  FUNCTIONS  MUST 
@@  BE  PROVIDED  BY  THE  USER.  PLEASE  TAILOR  FOR  YOUR 
@@  OWN  SPECIFIC  APPLICATION. 

***********************************************************/ 

/*********************************************************** 

Please  define  serial  communication  parameters  and  ring  buffer 
sizes  in  this  function. 

The  communication  parameters  that  must  be  set  are  the 
standard  asynchronous  (RS-232)  communication  parameters. 

The  parameters  are 

parity  :  NONE,  EVEN,  or  ODD; 
baud_rate  :  enter  any  standard  baud  rate; 
stopjoits :  ONE,  TWO,  or  ONE_AND_HALF ; 
transmit_data_size :  5,  6,  7,  or  8  (bits) ; 
receive_data_size :  5,  6,  7,  or  8  (bits) ; 
clock_multiplier :  1,  16,  32,  or  64 . 

Please  follow  syntax  given  in  the  template  function. 

Please  set  parameters  for  the  channels  used. 

Please  also  set  the  ring  buffer  size  to  be  used  for  the 
receive  buffer.  The  size  should  exceed  the  maximum 
anticipated  number  of  bytes  that  will  arrive  at  the 
IP-Serial  Module  during  one  sampling  interval. 

★  *****★**************★*★**★*******************■*★•*•★•*■**•*★*•*■*•**•  y' 

public  void  get_SERlAL_parameters 

(unsigned  int  hardware_channel, 

volatile  struct  user_param  *device_param, 
volatile  struct  ring_buf fer_param  *rec_buffer, 

IOdevice  *device) 

{ 

struct  user_type  *user_ptr; 
serial_param_type  *serptr; 

serptr  =  device->parameters; 

if  ( SERIAL_USER_PTR  ==  NULL) 

{ 

SERIAL_USER_PTR  =  (struct  user_type  * )malloc ( sizeof ( struct  user_type) ) 
user_ptr  =  SERI AL_USER_PTR ; 


user_ptr->update_interval  =  1000; 
user_ptr->update_count  =  0 ; 


if  (hardware_channel  ==  chanA  | |  hardware_channel  ==  chanB) 

{ 

/*  set  parameters  for  channel  A  (IP-SERIAL  channel  1)*/ 
device_param->parity  =  NONE; 

device_param->baud_rate  =  9600; 

device_param->stop_bits  =  ONE; 

device_param->transmit_data_size  =  8; 
device_param->receive_data_size  =  8; 
device_param->clock_multiplier  =  16; 

/*  set  size  for  receive  ring  buffer  */ 
rec_buf f er->buf fer_size  =  8000; 

} 

else 

{ 

printx( "INVALID  CHANNEL \n“ ) ; 

} 

}  /*  get_SERIAL_parameters  */ 


@@ 

Function 

@@ 

Abstract 

@@ 

@@ 

@@ 

@@ 

Input  s 

@@ 

@@ 

@@ 

@@ 

@@ 

Outputs 

@@ 

@@ 

Returns 

@@ 

user_poll_SERIAL_out 

Please  specify  user-defined  serial  output 
function  here.  Function  called  as 
scheduled  output  event . 

sysptr  (user-transparent  pointer  to 

system  attributes;  DO  NOT  MANIPULATE) 
model_f loat [ ]  (SystemBuild  output  vector) 
ser_channel  (serial  channel) 


error  status 


public  RetCode  user_SERIAL_out ( IOdevice  *device, 

float  model_f loat [] , 
u_int  ser_channel) 

{ 


/******************************************************** 

*  Given  floating  point  model  output,  please  create  * 

*  buffer  which  contains  bytes  to  be  transmitted  acros  * 

*  serial  channel.  * 

******************************************************** y 

/******************************************************** 

*  Fill  the  output  buffer  with  data  to  be  transmitted  * 

*  by  the  background  portion  of  the  serial  driver  * 

********************************************************y 

return  OK; 

}  /*  user_SERIAL_out  */ 


@@ 

@@ 

m 

@@ 

@@ 

@@ 

@@ 


Function 

Abstract 


Inputs 


user_sample_SERIAL_in 

Please  specify  user-defined  serial  input 
function  here.  Function  called  as 
scheduled  input  event . 

sysptr  (user-transparent  pointer  to 

system  attributes;  DO  NOT  MANIPULATE) 


@@  ser_channel  (serial  channel) 

@@ 

@@  Outputs  :  *model_float  (pass  back  floating  pt  vector) 
@@ 

@@  Returns  :  error  status 
@@ 

*************************************************/ 


public  RetCode  user_sample_SERIAL_in(IOdevice  *device, 

float  model_float [] , 
u_int  ser_channel) 


{ 


unsigned  char  item[l],  msgl [61] ,msg2 [115] ,  checksuml [1] ,  checksum2  [1] , 

mychecksuml,mychecksum2 ,  status,  model,  mode2,  mode3, 
mode4,  mode5,  mode6,  msg3[45],  checksum3 [1] , 
mychecksum3 ,  msg4[62],  checksum4  [1]  ,  mychecksum4; 

struct  user_type  *user_ptr; 

unsigned  long  i,  found  =  0,  icpl,  icp2,  icp3,  icp4,  icp5,  icp6, 

ephl ,  eph2 ,  eph3 ,  eph4 ,  eph5 ,  eph6 ; 

long  lat ,  Ion,  vel,  heigps,  heimsl; 

int  numl,  num2 ,  num3,  satl,  sat2,  sat3,  sat4,  sat5,  sat6, 

sattl,  satt2,  satt3,  satt4,  satt5,  satt6,  num4, 
velnor,  velup,  veleast; 

float-  psrngl,  psrng2,  psrng3 ,  psrng4,  psrngS,  psrng6, 

psrngratel,  psrngrate2,  psrngrate3,  psrngrate4, 
psrngrate5,  psrngrate6,  loctime,  sattimel, sattime2, 
sattime3,  sattime4,  sattime5,  sattime6,  ecefx,  ecefy, 
ecefz,  velnorl,  veleastl,  velupl,  hd,  timeref, 
pscorl,  pscor2,  pscor3 ,  pscor4,  pscor5,  pscor6, 
psrcorl,  psrcor2,  psrcor3,  psrcor4,  psrcor5,  psrcor6, 
locsec,  locsecf, 

satsecl,  satsec2,  satsec3,  satsec4, 
satsec5,  satsec6, satsecf 1,  satsecf2,  satsecf3, 
satsecf4,  satsecf5,  satsecf6,  heigpsl,  heimsll, 
veil,  latl,  lonl,  ecefxl,  ecefyl,  ecefzl; 


/********************************************************** 

*  set  user  pointer  to  buffer  allocated  by  get  parameters  * 

*  this  buffer  is  passed  around  with  the  structure  device  * 

*  and  should  only  be  accessed  via  the  SERIAL_USER_PTR  * 

*  define  * 

****************************************************^*****/ 

user_ptr  =  SERIAL_USER_PTR ; 


if (f irst_frame) 

{ 


for ( i=0 ; i<77 ; i++ ) 
last_f loat [i] =7 . 0 ; 
f irst_frame=false; 

icpoldl=0 . 0 ;  icpold2=0.0;  icpold3=0.0;  icpold4=0.D; 
icpold5=0.0;  icpold6=0.0; 

} 


READING  CHANNEL  A  ************************************/ 


-@@Ba- 


if  (ser_channel==l) 
{ 


numl  =  numbytes_in_buf fer (device->parameters) ; 


if  (numl  >  67) 


while ( found! =4 ) 

{ 

read_serial (device->parameters,  1, item) ; 
switch ( item[0] ) 

{ 

case ' @ ' : if ( f ound==0 ) 

found=l ; 

else  if  (found==l) 
f ound=2 ; 

else 

found=0 ; 

break; 

case'B':if  (found==2) 

f ound=3 ; 

else 

found=0 ; 

break ; 

case'a'rif  (found==3) 

f ound=4 ; 

else 

found=0 ; 

break; 

default : f ound=0 ; 

}/*end  switch*/ 

} /*end  while*/ 


/ *At  this  point  we  have  read  a  '@@Ba'  message*/ 


read_serial  ( device- >parameters,  61,  msgl) ; 
read_serial  (device->parameters, 1,  checksuml) ; 


/*Convert  message  bytes  to  numbers*/ 


lat  =  msgl [11] *0x1000000  +  msgl [12] *0x10000  +  msgl [13] *0x100  +  msgl [14]; 
Ion  =  msgl[15] *0x1000000  +  msgl [16] *0x10000  +  msgl [17] *0x100  +  msgl [18 ] ; 
heigps  =msgl [19] *0x1000000  +msgl [20] *0x10000  +msgl [21] *0x100  +  msgl [22]; 


heimsl  =  msgl [23 ] *0x1000000  +msgl [24 ] *0x10000  +msgl [25] *0x100  +msgl[26]; 
vel  =  msgl [27] *0x100  +  msgl [28]; 
hd  =  msgl [29] *0x100  +  msgl [30]; 
hd  =  hd/10.0; 
status  =  msgl [60]; 

vell=vel/100 . 0 ;  heigpsl=heigps/100 . 0 ;  heimsll=heimsl/100 . 0 ; 
latl=lat/100 . 0 ;  lonl=lon/100 . 0 ; 


/*check  if  message  is  correct*/ 

mychecksuml= ' B ' A ' a ' ; 
for ( i=0 ; i<61 ; i++) 
mychecksumlA=msgl [i] ; 


if (mychecksuml 1 =checksuml [ 0 ] ) 

for  ( i  =  0 ;  i  <  9 ;  i++ ) 

{ 

model_f loat [i]  =  last_f loat  [i] ; 

} 

else 

{ 

model_f loat [0] =latl; 
model_float [1] =lonl; 
model_f loat [2] =heigpsl ; 
model_float [3] =heimsll; 
model_float [4] =vell; 
model_f loat [5] =hd; 
model_f loat [6] =status ; 
model_f loat [ 7 ] =checksuml [ 0 ] ; 
model_f loat [ 8 ] =mychecksuml ; 


for  (i  =  0;  i  <  9;  i++) 

{ 

last_f loat [i]  =  model_f loat [i] ; 

} 

} /*endelse*/ 

}  /*endif*/ 


if(numl<=67) 

{ 

for  (i  =  0;  i  <  9;  i++) 

{ 

model_f loat [i]  =  last_f loat [i] ; 

} 

} 


/* 


*/ 


@@Bk' 


found=0 ; 

num4  =  numbytes_in_buf fer (device->parameters) ; 


if  (num4  >  68] 

{ 


while (found! =4) 

{ 

read_serial (device->parameters, 1, item) ; 
switch(item[0] ) 

{ 

case ' @ '  : if ( f ound==0 ) 

found=l ; 

else  if  (found==l) 
f ound=2 ; 

else 

founds 0 ; 

break; 

case 'B': if  (found==2) 

found=3 ; 

else 

found=0 ; 

break; 

case ' k': if  (found==3) 

found=4 ; 

else 

found=0 ; 

break; 


default : f ound=0 ; 
}/*end  switch*/ 
}/*end  while*/ 


/ *At  this  point  we  have  read  a  '@@Bk'  message*/ 

read_serial  (device->parameters,  62,  msg4) ; 
read_serial  (device->parameters,  1,  checksum4); 

/*Convert  message  bytes  to  numbers*/ 

ecefx  =msg4 [20] *0xl000000+msg4 [21] *0xl0000+msg4 [22] *100+msg4 [23] 

ecefy  =msg4 [24] *0x1000 000+msg4 [25] *0xl0000+msg4 [26] *100+msg4 [27] 

ecef z  =msg4 [28] *0xl000000+msg4 [29] *0xl0000+msg4 [30] *100+msg4 [31] 

ecefxl  =ecefx/10.0; 

ecefyl  =ecefy/10.0; 

ecefzl  =ecefz/10.0; 

velnor  =msg4 [12] *0xl00+msg4 [13] ; 

veleast  =msg4 [14] *0xl00+msg4 [15] ; 

velup  =msg4 [16] *0xl00+msg4 [17] ; 


if (velnor>5000 ) 
velnor=velnor-65536 ; 

if (veleast>5000 ) 
veleast=veleast-65536 ; 

if (velup>5000 ) 
velup=velup-65536 ; 

velnorl  =velnor/10 . 0 ; 

veleastl  =veleast/10 . 0 ; 

velupl  =velup/10.0; 


/*check  if  message  is  correct*/ 


mychecksum4  = ' B ' A ' k '  ; 
for ( i=0 ; i<62 ; i++ ) 
mychecksum4^=msg4 [i] ; 

if (mychecksum4 !=checksum4 [0] ) 

{ 

for  (i  =  69;  i  <  77;  i++) 

{ 

model_f loat [ i— 2  7 ]  =  last_f loat [i] ; 

> 

} 

else 

{ 


mode l_f loat [42] 
mode l_f loat [43 ] 
mode l_f loat [44] 
model_float [45] 
mode l_f loat [46 ] 
model_float [47] 
mode l_f loat [48] 
model_float [49] 


=ecefxl; 
=ecefyl ; 

=ecef zl; 
=velnorl ; 
^veleastl ; 
=velupl ; 
=checksum4 [ 0 ] ; 
=mychecksum4  ; 


for  (i  =  42;  i  <  50;  i++) 

{ 

last_f loat [i+27]  =  model_f loat [i] 

} 


} /*endelse*/ 


}/*endif */ 


if (num4<=68 ) 

{ 

for  (i  =  69;  i  <  77;  i++) 

{ 

model_f loat [i-27] 

} 


last_f loat [i] ; 


found=0 ; 

num2  =  numbytes_in_buffer (device->parameters) ; 


if  (num2  >  121) 

{ 

while (found! =4) 

{ 

read_serial (device->parameters, 1, item) ; 
switch (item[0] ) 

{ 

case ' @ ' : if ( f ound==0 ) 

found=l ; 

else  if  (found==l) 
f ound=2 ; 

else 

found=0 ; 

break; 

case 'B'; if  (found==2) 

found=3 ; 

else 

found=0 ; 

break; 

case'g':if  (found==3) 

f ound=4 ; 

else 

founds 0 ; 

break; 

default : found=0 ; 

}/*end  switch*/ 

} /*end  while*/ 


/ *At  this  point  we  have  read  a  '@@Bg'  message*/ 

read_serial  (device->parameters ,  115,  msg2) ; 
read_serial  (device->parameters, 1,  checksum2); 


/*Convert  message  bytes  to  numbers*/ 


locsec  =msg2 [0] *0x10000  +msg2 [1] *0x100  +msg2[2]; 

locsecf  =msg2 [3 ] *0x1000000  +msg2 [4] *0x10000  +msg2 [5] *0x100  +msg2[6]; 

/*  GPS  channell  data  */ 
satl  =msg2[7]; 
model  =msg2[8]; 

satsecl  =msg2 [9] *0x10000  +msg2 [10] *0x100  +msg2[ll]; 

satsecfl=msg2 [12] *0x1000000  +msg2 [13] *0x10000  +msg2 [14] *0x100  +msg2[15]; 
icpl  =msg2 [16] *0x1000000  +msg2 [ 17 ] *0x10000  +msg2 [ 18] *0x100  +msg2[19]; 

/*  GPS  channel2  data  */ 
sat 2  =msg2[25]; 
mode2  =msg2 [26] ; 

satsec2  =msg2 [27] *0x10000  +msg2 [28] *0x100  +msg2[29]; 

satsecf2=msg2 [30] *0x1000000  +msg2 [31] *0x10000  +msg2 [32] *0x100  +msg2[33]; 
icp2  =msg2 [34] *0x1000000  +msg2 [35] *0x10000  +msg2 [36] *0x100  +msg2[37]; 

/*  GPS  channel3  data  */ 
sat3  =msg2[43]; 
mode 3  =msg2 [44] ; 

satsec3  =msg2 [45] *0x10000  +msg2 [46] *0x100  +msg2[47]; 

satsecf3=msg2 [48] *0x1000000  +msg2 [49] *0x10000  +msg2 [50] *0x100  +msg2[51]; 
icp3  =msg2 [52] *0x1000000  +msg2 [53 ] *0x10000  +msg2 [54] *0x100  +msg2[55]; 

/*  GPS  channel4  data  */ 
sat 4  =msg2[61]; 
mode 4  =msg2 [62] ; 

satsec4  =msg2 [63] *0x10000  +msg2 [64] *0x100  +msg2[65]; 

satsecf4=msg2 [66] *0x1000000  +msg2 [67] *0x10000  +msg2 [68] *0x100  +msg2[69]; 
icp4  =msg2 [70]*  0x1 000000  +msg2 [71] *0x10000  +msg2 [72] *0x100  +msg2[73]; 

/*  GPS  channel5  data  */ 
sat 5  =msg2[79]; 
mode  5  =msg2 [80] ; 

satsec5  =msg2 [81] *0x10000  +msg2 [82] *0x100  +msg2[83]; 

satsecf 5=msg2 [84] *0x1000000  +msg2 [85] *0x10000  +msg2 [86] *0x100  +msg2[87]; 


icp5  =msg2 [88] *0x1000000  +msg2 [89] *0x10000  +msg2 [90] *0x100  +msg2[91]; 


/*  GPS  channel6  data  */ 
sat6  =msg2[97]; 
mode6  =msg2 [98] ; 

satsec6  =msg2 [99] *0x10000  +msg2 [100] *0x100  +msg2[101]; 
satsecf 6=msg2 [102] *0xl000000+msg2 [103] *0xl0000+msg2 [104] *0xl00+msg2 [105] 
icp6=msg2 [106] *0x1000000  +msg2 [107] *0x10000  +msg2 [108] *0x100  +msg2[109] 


/*check  if  message  is  correct*/ 


mychecksum2='B,/wg'  ; 
for ( i=0 ; i<115 ; i++ ) 
mychecksum2/'=msg2  [i]  ; 

if (mychecksum2  j =checksum2 [0] ) 

{ 

for  (i  =  9;  i  <  42;  i++) 

{ 

mode l_fl oat [i]  =  last_f loat [i] ; 

} 

} 

else 

{ 

/*Satellite  and  receiver  GPS  time  (sec)*/ 

loctime  =locsec  +locsecf/ (pow(10 . 0, 9 . 0) ) ; 
sattimel  =satsecl  +satsecfl/ (pow(10 . 0, 9 . 0) ) ; 
sattime2  =satsec2  +satsecf2/ (pow(10 .0, 9 . 0) ) ; 
sattime3  =satsec3  +satsecf3/ (pow(10 . 0, 9 . 0) ) ; 
sattime4  =satsec4  +satsecf4/ (pow(10 . 0, 9 . 0) ) ; 
sattime5  =satsec5  +satsecf5/ (pow(10 .0,9.0)); 
sattime6  =satsec6  +satsecf 6/ (pow(10 . 0, 9 . 0) ) ; 

/*Pseudoranges  (m)*/ 

psrngl  =( loctime  -  sattimel ) *sol ; 
psrng2  =( loctime  -  sattime2 ) *sol; 
psrng3  =(loctime  -  sattime3 ) *sol ; 
psrng4  =( loctime  -  sattime4) *sol; 
psrng5  =( loctime  -  sattime5 ) *sol ; 
psrng6  =(loctime  -  sattime6)*sol; 

k2=sol/( Ilf 0*65536.0) ; 

/*Pseudorange  rates  (m/sec)*/ 

psrngratel  =k2*(icpl  -  icpoldl) ; 
psrngrate2  =k2*(icp2  -  icpold2); 
psrngrate3  =k2*(icp3  -  icpold3); 
psrngrate4  =k2*(icp4  -  icpold4); 


psrngrate5  =k2*(icp5  -  icpold5); 
psrngrate6  =k2*(icp6  -  icpold6) ; 


icpoldl  =icpl; 
icpold2  =icp2; 
icpold3  =icp3; 
icpold4  =icp4; 
icpold5  =icp5; 
icpold6  =icp6; 


model_float [9] 
model_float [10] 
mode l_fl oat [11] 
model_f loat [ 12 ] 
model_float [13] 
model_f loat [ 14 ] 
mode l_f loat [15] 
model_float [16] 
model_float [17] 
mode l_f loat [18] 
model_float [19] 
mode l_f loat [20] 
mode l_f loat [21] 
mode l_f loat [22 ] 
model_float [23] 
model_float [24] 
model_f loat [25] 
mode l_f loat [26] 
mode l_f loat [27] 
mode l_f loat [28] 
mode l_f loat [29] 
mode l_f loat [30] 
mode l_f loat [31] 
mode l_f loat [32] 
mode l_f loat [33] 
mode l_f loat [34] 
mode l_f loat [35] 
mode l_f loat [36] 
mode l_f loat [37] 
mode l_f loat [38] 
mode l_f loat [39 ] 
mode l_f loat [40] 
mode l_f loat [41] 


=  loctime; 

=  satl; 

=  model; 

=  sattimel; 

=  psrngl; 

=  psrngratel; 

=  sat2 ; 

=  mode 2 ; 

=  sattime2; 

=  psrng2 ; 

=  psrngrate2; 

=  sat  3; 

=  mode 3 ; 

=  sattime3; 

=  psrng3 ; 

=  psrngrate3  ; 

=  sat4; 

=  mode 4 ; 

=  sattime4; 

=  psrng4; 

=  psrngrate4; 

=  sat5; 

=  mode 5 ; 

=  sattime5; 

=  psrng5; 

=  psrngrateS; 

-  sat6; 

=  mode  6  ; 

=  sattime6; 

=  psrng6; 

=  psrngrate6; 

=  checksum2 [0] ; 
=  mychecksum2 ; 


for  (i  =  9;  i  <  42 ;  i++) 

{ 

last_f loat [i]  =  model_f loat [i] 

} 

}/*endelse*/ 

}  /*endif */ 


if (num2<=121) 

{ 


for  (i  =  9;  i  <  42;  i++) 

{ 

model_f loat [i]  =  last_f loat [i] ; 

} 


}/*endif  ser_channell*/ 


if  (ser  channel==0) 


found=0 ; 

num3  =  numbytes_in_buf f er (device->parameters) ; 


if  (num3  >  51) 


while ( found! =4 ) 

{ 

read_serial (device->parameters, 1 , item) ; 
switch (item[0] ) 

{ 

case ' @ ' : if ( f ound==0 ) 

found=l ; 

else  if  (found==l) 
f ound=2 ; 

else 

found=0 ; 

break; 

case ' C ' : if  ( f ound==2 ) 

f ound=3 ; 

else 

founds 0 ; 

break; 

case'e':if  (found==3) 

founds 4 ; 

else 
break ; 


default : f ound=0 ; 
}/*end  switch*/ 
}/*end  while*/ 


f ound=0 ; 


/ *At  this  point  we  have  read  a  '@@Ce'  message*/ 

read_serial  (device->parameters,  45,  msg3 ) ; 
read_serial  (device->parameters, 1,  checksum3); 

/*Convert  message  bytes  to  numbers*/ 


/*GPS  time  reference*/ 

timeref  =msg3 [0] *0x10000  +msg3 [1] *0x100  +msg3[2]; 

/*  Differential  corections  */ 

/*  Channell  data  */ 

sattl  =msg3[3]; 

pscorl  =msg3 [4] *0x10000  +msg3 [5] *0x100  +msg3[6]; 
psrcorl  =msg3 [7] *0x100  +msg3[8]; 
ephl  =msg3 [ 9 ] ; 

/*  Channel2  data  */ 

satt2  =msg3[10]; 

pscor2  =msg3 [11] *0x10000  +msg3 [12] *0x100  +msg3[13] 
psrcor2  =msg3 [14] *0x100  +msg3[15]; 
eph2  =msg3[16]; 

/*  Channel3  data  */ 

satt3  =msg3[17]; 

pscor3  =msg3 [18] *0x10000  +msg3 [19] *0x100  +msg3[20] 
psrcor3  =msg3 [21] *0x100  +msg3[22]; 
eph3  =msg3[23]; 

/*  Channel4  data  */ 

satt4  =msg3[24]; 

pscor4  =msg3 [25] *0x10000  +msg3 [26] *0x100  +msg3[27] 
psrcor4  =msg3 [28] *0x100  +msg3[29]; 
eph4  =msg3[30]; 

/*  Channel5  data  */ 

satt5  =msg3[31]; 

pscor5  =msg3 [32 ] *0x10000  +msg3 [33] *0x100  +msg3[34] 
psrcor5  =msg3 [35] *0x100  +msg3[36]; 
eph5  =msg3[37]; 

/*  Channel6  data  */ 

satt6  =msg3[38]; 

pscor6  =msg3 [39] *0x10000  +msg3 [40] *0x100  +msg3[41] 
psrcor6  =msg3 [42] *0x100  +msg3[43]; 
eph6  =msg3[44]; 


/*check  if  message  is  correct*/ 


mychecksum3  = ' C ' A ' e ' ; 
for ( i=0 ; i<45 ; i++) 
mychecksum3^=msg3 [i] ; 

if (mychecksum3 !=checksum3 [0] ) 

{ 

for  (i  =  42;  i  <  69;  i++) 

{ 


model_f loat [i-42]  =  last_f loat [i] ; 

> 

} 

else 

{ 

timeref  =timeref /10 . 0 ; 

/*Pseudorange  correction  (m)*/ 

pscorl  =pscorl/ (pow(10, 2) ) ; 
pscor2  =pscor2/ (powdO ,  2 )  )  ; 
pscor3  =pscor3/ (pow(10, 2) ) ; 
pscor4  =pscor4/ (pow(10, 2) ) ; 
pscor5  =pscor5/ (pow(10 , 2 ) ) ; 
pscor6  =pscor6/ (powdO ,  2 )  )  ; 

/*Pseudorange  rate  correction  (m/sec)*/ 

psrcorl  =psrcorl/ (pow(10, 3) ) ; 
psrcor2  =psrcor2/ (pow(10, 3 ) ) ; 
psrcor3  =psrcor3 / (pow ( 10 , 3 ) ) ; 
psrcor3  =psrcor3/ (pow (10, 3) ) ; 
psrcor3  =psrcor3/ (pow( 10, 3 ) ) ; 
psrcor4  =psrcor4/ (pow(10 , 3 ) ) ; 


mode l_f loat [0]  =timeref; 
mode l_f loat [1]  =sattl; 
model_float [2]  =pscorl; 
model_f loat [3]  =psrcorl; 
model_f loat [4]  =ephl; 
mode l_f loat [5]  =satt2; 
model_float [6]  =pscor2 ; 
mode l_f loat [ 7 ]  =psrcor2 ; 
model_f loat [8]  =eph2 ; 
model_f loat [9]  =satt3; 
model_f loat [10]  =pscor3 ; 
model_f loat [11]  =psrcor3; 
mode l_f loat [12]  =eph3; 
model_f loat [ 13 ]  =satt4 ; 
model_f loat [ 14 ]  =pscor4 ; 
mode l_f loat [ 15 ]  =psrcor4 ; 
model_f loat [16]  =eph4 ; 
model_float [17]  =satt5; 
model_f loat [ 18 ]  =pscor5 ; 
model_f loat [19]  =psrcor5; 
model_f loat [20]  =eph5; 
model_float [21]  =satt6; 
model_float [22]  =pscor6; 
model_f loat [23 ]  =psrcor6; 
model_f loat [24]  =eph6; 
model_float  [25]  =checks-um3  [0]  ; 
model_f loat [26]  =mychecksum3  ; 


for  (i  =  42;  i  <  69;  i++) 

{ 

last_f loat [i]  =  model_f loat [i-42 ] ; 
} 


}  /*endelse*/ 


} /*endif */ 


if (num3<=51) 

{ 

for  (i  =  42;  i  <  69;  i++) 

{ 

model_f loat [ i-42 ]  =  last_f loat [i] ; 

} 

} 


}/*endif  ser_channelO*/ 


return  OK; 


}  /*  user_sample_SERIAL_in  */ 

END  OF  FILE 


APPENDIX  D. :  USER  SER.C-BK  PROJECT 


USER  SER.C 


PROJECT  bk 


:  File  :  user_ser.c 

!  Project  :  Acl00/c30 
1  Edit  level  :  3 


Abstract:  :  File  contains  functions  which  the  user 

must  define  to  interface  with  IP-SERIAL  device 
driver . 

The  functions  must  be  called 

get_SERIAL_parameters 

user_poll_SERIAL_out 

user_sample_SERIAL_in 

Templates  for  the  functions  are  provided. 
get_SERlAL_jparameters 

Function  sets  the  asynchronous  communication 
parameters  for  the  IP-SERIAL  module.  Ring  buffer 
sizes  used  to  store  received  data  must  also  be 
specified. 

user_poll_SERIAL_out 

Function  is  called  with  the  floating-point 
model  output  vector  for  the  current  sampling  interval. 
The  user  is  responsible  for  creating  the  transmit 
byte  array  and  calling  function  write_serial  which 
transmits  the  byte  array  across  the  serial  channel. 

user_sample_SERIAL_in 

Function  is  called  every  sampling  interval.  The 
user  is  responsible  for  filling  the  floating-point 
vector  which  is  used  as  input  to  the  model  for 
the  current  sampling  interval . 


*  *@ 

Modifications : 

Creation  : 

7-1  —  93 

Henry 

Tomin< 

**@ 

Revised  : 

8-23-93 

Brent 

Roman 

Revised  : 

11-18-93 

Steve 

Lynch 

**@ 

Revised  : 

4-27-95 

Christof is 

# include 
# include 
# include 
#include 
# include 
#include 
# include 
# include 
# include 


<stddef .h> 
<stdlib.h> 
"sa_types .h“ 
"types .h" 

" ioerrs .h" 

" errcodes .h" 
* iodriver .h" 
* ipserial .h" 
“prihtx.h" 


#def ine  NULL  0 


/*  semaphores  and  serial  parameters  for  each  physical  channel  */ 
private  struct 

{  boolean  allSent;  boolean  broken;  unsigned  baud;}  line_state [2] ; 

struct  user_type 

{ 

int  update_interval ; 
int  update_count ; 


}; 

/*********************************************************** 

*********************************************************** 

@@  THE  INTERNALS  OF  THE  FOLLOWING  THREE  FUNCTIONS  MUST 
@@  BE  PROVIDED  BY  THE  USER.  PLEASE  TAILOR  FOR  YOUR 
@@  OWN  SPECIFIC  APPLICATION. 

*********************************************************** 

***************★***********•*■**•*■**★*★**■*■*********•***■*■*■*****★/ 


/*********************************************************** 

Please  define  serial  communication  parameters  and  ring  buffer 
sizes  in  this  function. 

The  communication  parameters  that  must  be  set  are  the 
standard  asynchronous  (RS-232)  communication  parameters. 

The  parameters  are 

parity  :  NONE,  EVEN,  or  ODD; 

baud_rate  :  enter  any  standard  baud  rate; 

Stopjoits:  ONE,  TWO,  or  ONE_AND_HALF ; 
transmit__data__size :  5,  6,  7,  or  8  (bits); 
receive_data_size :  5,  6,  7,  or  8  (bits) ; 
clock__mult iplier :  1,  16,  32,  or  64. 

Please  follow  syntax  given  in  the  template  function. 

Please  set  parameters  for  the  channels  used. 

Please  also  set  the  ring  buffer  size  to  be  used  for  the 
receive  buffer.  The  size  should  exceed  the  maximum 
anticipated  number  of  bytes  that  will  arrive  at  the 
IP-Serial  Module  during  one  sampling  interval. 
************************************************************ ^ 
public  void  get_SERIAL_parameters 

(unsigned  int  hardware_channel , 

volatile  struct  user_param  *device_param, 
volatile  struct  ring_buf f er_param  *rec_buffer, 

IOdevice  * device) 

{ 

struct  user_type  *user_ptr; 
serial_jparam_type  *serptr ; 

serptr  =  device->parameters ; 

if  ( SERIAL_USER_PTR  ==  NULL) 

{ 

SERIALJJSER__PTR  =  (struct  user_type  *) malloc ( sizeof ( struct  user_type) ) ; 
user_ptr  =  SERIAL_USER_PTR; 

user_ptr->update_interval  =  1000; 
user_ptr->update_count  =  0; 

} 


if  (hardware_channel  ==  chanA  | |  hardware_channel  ==  chanB) 
{ 

/*  set  parameters  for  channel  A  (IP-SERIAL  channel  1)*/ 


device_param->parity  =  NONE; 

device_param->baud_rate  =  9600; 

device_param->stop_bits  -  ONE; 

device_param->transmit_data_size  =  8; 
device_param->receive_data_size  =  8; 
device_param->clock_multiplier  =  16; 

/*  set  size  for  receive  ring  buffer  */ 
rec_buf  fer->buf  fer_size  =  1500; 


} 

else 

{ 

printx ( " INVALID  CHANNEL \n" ) ; 

} 

}  /*  get_SERIAL_parameters  */ 

/************************************************ 

@@  Function  :  user_poll_SERIAL_out 

@@  Abstract  :  Please  specify  user-defined  serial  output 

@@  function  here.  Function  called  as 

@@  scheduled  output  event. 

@@ 

@@  Inputs  :  sysptr  (user-transparent  pointer  to 

@@  system  attributes;  DO  NOT  MANIPULATE) 

@@  model_f loat [ ]  (SystemBuild  output  vector) 

@@  ser_channel  (serial  channel) 

@@ 

@@  Outputs  : 

@@ 

@@  Returns  :  error  status 

@@ 

**********★****★*********★*****★************★****/ 


unsigned  char  my_float[8],  checksum=0x00 ; 


public  RetCode  user_SERIAL_out ( IOdevice  *device, 

float  model_f loat [] , 
u_int  s  e  r_channe 1 ) 

{ 


checksum^ ' B ' A ' k ' ; 
checksum-' =0x01; 

my_float [0]  =  '@'  ; 
my_f loat [ 1 ]  =  '  @ '  ; 
itry_float  [2]  =  'B'  ;  ■ 
my_float [3] ='k' ; 
my_float [4] =0x01; 
my_f loat [5] =checksum; 
my_float [6] ='\r' ; 
my_f loat [7] =' \n' ; 


/********************************************************* 

*  Given  floating  point  model  output,  please  create  * 

*  buffer  which  contains  bytes  to  be  transmitted  across  * 

*  serial  channel.  * 

****************************** ***************************/ 


/******************************************************** 

*  Fill  the  output  buffer  with  data  to  be  transmitted  * 

*  by  the  background  portion  of  the  serial  driver  * 

********************************************************  j 


write_serial (device->parameters,my_float, 8) ; 


return  OK; 


}  /*  user_SERIAL_out  */ 


/************************************************ 

@@  Function  :  user_sample_SERIAL_in 

@@  Abstract  :  Please  specify  user-defined  serial  input 

@@  function  here.  Function  called  as 

@@  scheduled  input  event . 

@@ 

@@  Inputs  ;  sysptr  (user-transparent  pointer  to 

@@  system  attributes;  DO  NOT  MANIPULATE) 

@@  ser_channel  (serial  channel) 

@@ 

@@  Outputs  :  *model_float  (pass  back  floating  pt  vector) 

@@ 

@@  Returns  :  error  status 
@@ 

*************************************************  j 

public  RetCode  user_sample_SERIAL_in(IOdevice  *device, 

float  model_f loat [ ] , 
u_int  ser_channel) 

{ 

struct  user_type  *user_ptr; 


/******************************************************* 

*  set  user  pointer  to  buffer  allocated  by  get  parameters 

*  this  buffer  is  passed  around  with  the  structure  device 

*  and  should  only  be  accessed  via  the  SERIAL_USER_PTR 

*  define 

******************************************************** 
user_ptr  =  SERIAL_USER_PTR ; 


return  OK; 


}  /*  user_sample_SERIAL_in  */ 
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